Main Page | Directories | Namespace List | Class Hierarchy | Alphabetical List | Class List | File List | Namespace Members | Class Members | File Members | Related Pages | Examples

Development Targets and Usage Preconditions of IsoAgLib

Object Oriented Program Library ISOAgLib

Development of ISO 11783 and DIN 9684 Applications

Copyright © 1999 - 2004 Achim Spangler, Martin Wodok

Licensed with Exceptions under the General Public License (GPL) of the Free Software Foundation

News
Changes
Main Features
Structural Overview
License Conditions
Acknowledgements
Thanks to development by Sensortechnik Wiedemann ( STW )
Thanks to Fritzmeier for contribution of ISO 11783 Virtual Terminal support
Thanks to eager and patient initial developers with Win32
Main TODO items
Authors and Contributors of the IsoAgLib
List of Known Projects which use IsoAgLib
HOWTO Identify and download needed archives
HOWTO Access the Version Management Repository
HOWTO Recreate Documentation with Doxygen
HOWTO Learn Usage of IsoAgLib
HOWTO Prepare Suitable Compiler and IDE
HOWTO Install vt2iso - Tool for Creation of ISO 11783 Virtual Terminal Masks
HOWTO Create Project Files with Script update_makefile.sh
General Information
Modelling as Network of Autonomous Agents
Service Network
Requirements
Further Development
Examples
Questions, Answers and Discussion
Further Reading on Open Source

 
 
 
Last Update:
13 October 2004
by Achim Spangler

General Information

The ISOAgLib was primarily developed for massive automatic process data recording within the research group IKB-Dürnast . Since publishing of this project it is used for:

Task Controller which retrieves GPS information from a Fieldstar (TM) terminal, combines them with dynamic detected process data of pre configured IMI types and polls the information via RS232 to a PC or PCMCIA Flashdisk in simple table format. Last but not least it measures the hitch force (with sensors of EHR) and the fuel consumption and polls them, too. The Task Controller detects dependent on GPS, if the actual position is in one of the configured (EEPROM) areas of type mounting, transport or field. With this it can gather the information for each area type in its own subset.

 

The main basic design principles of the ISOAgLib are:

 

The ISOAgLib version 1.0.0rc1 is running stable, as it's already used for the Chlorophyll Sensor MiniVeg N of the manufacturer Fritzmeier . As it's verified with automated tests, that the final device is fitting to all defined requirements, the ISOAgLib will at least provide a robust correct function at least for this application.

In case the ISOAgLib would suffer some problems for other applications, you can be shure that the author Achim Spangler maintains this project actively.

Modelling as Network of Autonomous Agents

The targeted flexible network, where devices of different manufacturers, models and built years are providing and using general services can be seen as a network of partial autonomous agents. Kühnel establishes the following criteria for the use of agents in the view of the whole system (book: "Agentenbasierte Softwareentwicklung", A.: Ralf Kühnel, V.: Addison-Wesley):

Knowledge Management System

  1. application can simply store and update local process data information
  2. optional periodic store of actual value in EEPROM
  3. periodic or one time information requests from remote devices are handled in the background
  4. capable support for one time or periodic information request (including request of MIN or MAX on specific trigger events)
  5. several remote devices can independently reset the stored value, if they have registered a measuring program (time or distance proportional or value dependent triggered sending of values)
  6. process data can be flexible created or deleted during runtime to adopt to actual information needs
  7. all information types are handled with the same API
  8. each information type (e.g. application rate) is addressed by an unique identifier which contains the device type (e.g. spreader), mounting position and location in the device specific dictionary so that dynamic source address or protocol type (DIN 9684 or ISO 11783) is irrelevant for the application design

Control Interaction

  1. API of each process data has subgroups for measurement information and work control
  2. setpoints can be defined as exact values, MIN or MAX limits or intervals
  3. information if sent setpoint was answered with accept or reject (differentiated by reason)
  4. information if previously rejected setpoint is still consistent with the actual measurement value
  5. parallel received setpoints for the same process data are distinguished by sender ident, so that selective accept and reject is possible
  6. accepted setpoint sender is marked as MASTER, so that succeeding setpoints of the MASTER can be distinguished from setpoints of other devices
  7. optional automatic information of setpoint MASTER, if actual measurement value exceeds the configurable admissible tolerance

Service Network

The interactions between the devices of a DIN 9684 or ISO 11783 network can be modelled as the providing and using of construction independent services. This is illustrated with the following diagrams.
service_network_connection.gif
 
 
 

The devices of this network are using and providing services as process data. The correct function of the elements is only possible, if no device is dependent on a service of another not existent device.


service_network_conflict.gif
 
 
 
Resource conflicts can occur, if several devices want to control the driving speed and RPM of PTO of the tractor. Therefore each implement should avoid the sending of exact setpoints in favour of intervals.



service_network_flexibility.gif
 
 
 Several implements which want to control the work of the tractor are no problem, if they define intervals instead of exact values. Additionally they should use process data which are as abstract as possible.
The rotary harrow could define setpoints for driving speed and PTO of the tractor, so that the tractor would be fixed very tight to the needs of the on implement. This wouldn't allow the fertilizer to control the driving speed.

If the rotary harrow defines alternatively the relation between driving speed and PTO, the tractor can realize this setting for different speeds (dependent on the transmission of the tractor). The tractor can regard the setpoint from the fertilizer in this case.


Requirements

Platform

The ISOAgLib is running on the following systems (state 05 April 2004):

Compiler

The object oriented design of the ISOAgLib is implemented with C++ and uses the features namespaces and templates. The "Standard Template Library" (STL) is used as proven and high quality implementation of dynamic lists for monitor lists, process data, etc. .Therefore a modern (old versions often implement some parts wrong or produce bad code) C++ compiler is needed. Actual optimizing technologies allow program size and execution speed which is equivalent or better than comparable C implementations.
Suitable compilers exists for processors with at least 16 Bit (e.g. the C16x series). For quick process data management (which are standardized as 32 Bit values) and more flexible heap memory access, a 32 Bit processor is appropriate. But as all research work is performed with the ECU ESX of STW which uses the Infineon 16 Bit processor C167, a 32 Bit processor is not obligatory.
From spring 2002 on all three well known compiler manufacturers (Tasking , HighTec and KEIL ) provides a suitable C++ compiler for C16x processors. The company Comeau Computing creates a C++ extension for a C compiler on demand. Quick high quality integration of C++ into C compilers is possible with the help of the state of the art C++ front-end of EDG which have a customer reference list of some well known brands .
As soon as a project is compiled by a C++ aware compiler, a project can integrate parts written in C and C++ without any problems.

Memory

Dependent on the intensity of process data use, the ISOAgLib needs in most cases less than 16 Kbytes of RAM. More detailed documentation has to be created with the new process data management, which doesn't occupy heap memory for unneeded functions like setpoint management, when only measurement values are communicated (new feature in 0.2.0).
The ISOAgLib needs with the minimum module configuration about 66 Kbytes Flash ROM. A configuration with full featured with process data needs about 106 Kbytes Flash ROM.
The RAM and Flash ROM size depends heavily on the configuration of the ISOAgLib and on the optimizing capabilities of the compiler.

Programming Skills

As long as the ISOAgLib should only be used as it is, without analysing or optimizing it, the needed additional C++ skills (in relation to C) are small. The actual 24 tutorial examples and the three real research world examples provides a sufficient introduction in the usage of C++ and the ISOAgLib.
As soon as the internals of the ISOAgLib should be understood, the needed level of C++ skills is increased dependent on the configuration of the ISOAgLib. Companies who are interested in a reliable guarantee, that needed bugfixes or extensions are realized by external developers (if local developers are not familiar with C++ and the ISOAgLib), should contact Achim Spangler to establish commercial support contracts including training, project attendance and ISOAgLib ISO 900x certification.

Everybody who want to get familiar with the ISOAgLib should start with the tutorial examples.


Generated on Wed Oct 13 15:16:24 2004 for IsoAgLib by  doxygen 1.3.8-20040913