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

Process Data Management with IsoAgLib

The IsoAgLib provides a very capable management of Process Data as standard mechanism ( IsoAgLib::iProcDataLocal_c and IsoAgLib::iProcDataRemote_c ). But as this might cause a big overhead for some applications, which for example only want to publish some measurement data on the BUS, restricted variants of them are provided.

Overview on type of Process Data


Local Process Data

Therefore the following variants are provided for local Process Data
( local means: the ECU which performs this SW is responsible for measurement and update of the value; additionally it is the adressee for setpoint commands ):

Remote Process Data

The access to remote Process Data, which corresponds to data aquired by remote ECUs provides similar levels of capability:

Distribution of Classes and their corresponding files

The different variants of local and remote Process Data are based on some helper classes. The helper classes are structured corresponding to the feature set levels described in the overview on types of Process Data. The subdirectories are structured so that the needed main and helper classes for a wanted Process Data variant can be easily found.
E.g. classes which are responsible for standard ( capable ) measuring programs of a Process Data type reside in the directories named StdMeasureElements.
Comparable, the helper classes for a process data type which provides only restricted ( simple ) setpoint management are placed in directories named SimpleMeasureElements.
This leads to the following subdirectory structure beneath <lgpl_src/IsoAgLib/comm/Process> Like in all directories of IsoAgLib, the internal implementation class Foo_c resides in path/impl/foo_c.h with path/ifoo_c.h for the interface class iFoo_c. Thereby the individual elements of the impl subdirectories are not described in this context - simply incorporate the contents of <path/impl>, if you take any class of path.
Local classes for local process data types
-> ECU which runs this SW is responsible to update measurement value and react on setpoint ( if used )
Remote classes for remote process data types
-> remote ECU provides services for this process data
StdMeasureElements helper classes for both remote and local measurement programs
( thereby placed in this central directory )
StdSetpointElements helper classes for both remote and local capable setpoint handling
( thereby placed in this central directory )
impl implementation files for all central classes which are needed for all Process Data applications
( -> include the elements of this directory always if you use Process Data )
LocalStdfiles for IsoAgLib::iProcDataLocal_c
need files of Local/StdMeasureElements, Local/StdSetpointElements, StdMeasureElements, StdSetpointElements and impl ( everything related to Process directory )
LocalSimpleMeasurefiles for IsoAgLib::iProcDataLocalSimpleMeasure_c
need files of Local/StdSetpointElements, StdSetpointElements and impl ( everything related to Process directory )
LocalSimpleSetpointfiles for IsoAgLib::iProcDataLocalSimpleSetpoint_c
need files of Local/StdMeasureElements, Local/SimpleSetpointElements, StdMeasureElements and impl ( everything related to Process directory )
LocalSimpleMeasureSetpointfiles for IsoAgLib::iProcDataLocalSimpleSetpointSimpleMeasure_c
need files of Local/SimpleSetpointElements and impl ( everything related to Process directory )
LocalStdMeasureElementshelper classes for IsoAgLib::iProcDataLocal_c and IsoAgLib::iProcDataLocalSimpleSetpoint_c
LocalStdSetpointElementshelper classes for IsoAgLib::iProcDataLocal_c and IsoAgLib::iProcDataLocalSimpleMeasure_c
LocalSimpleSetpointElementshelper classes for IsoAgLib::iProcDataLocalSimpleSetpoint_c and IsoAgLib::iProcDataLocalSimpleSetpointSimpleMeasure_c
Localimplfiles for all local Process Data types
RemoteStdfiles for IsoAgLib::iProcDataRemote_c
need files of Remote/StdMeasureElements, Remote/StdSetpointElements, StdMeasureElements, StdSetpointElements and impl ( everything related to Process directory )
RemoteSimpleMeasurefiles for IsoAgLib::iProcDataRemoteSimpleMeasure_c
need files of Remote/SimpleMeasureElements, Remote/StdSetpointElements, StdSetpointElements and impl ( everything related to Process directory )
RemoteSimpleSetpointfiles for IsoAgLib::iProcDataRemoteSimpleSetpoint_c
need files of Remote/StdMeasureElements, Remote/SimpleSetpointElements, StdMeasureElements and impl ( everything related to Process directory )
RemoteSimpleMeasureSetpointfiles for IsoAgLib::iProcDataRemoteSimpleSetpointSimpleMeasure_c and IsoAgLib::iProcDataRemoteSimpleSetpointSimpleMeasureCombined_c
need files of Remote/StdMeasureElements ( only for IsoAgLib::iProcDataRemoteSimpleSetpointSimpleMeasure_c ), Remote/SimpleSetpointElements and impl ( everything related to Process directory )
RemoteStdMeasureElementshelper classes for IsoAgLib::iProcDataRemote_c and IsoAgLib::iProcDataRemoteSimpleSetpoint_c
RemoteStdSetpointElementshelper classes for IsoAgLib::iProcDataRemote_c and IsoAgLib::iProcDataRemoteSimpleMeasure_c
RemoteSimpleSetpointElementshelper classes for IsoAgLib::iProcDataRemoteSimpleSetpoint_c and IsoAgLib::iProcDataRemoteSimpleSetpointSimpleMeasure_c
RemoteSimpleMeasureElementshelper classes for IsoAgLib::iProcDataRemoteSimpleMeasure_c, IsoAgLib::iProcDataRemoteSimpleSetpointSimpleMeasure_c and IsoAgLib::iProcDataRemoteSimpleSetpointSimpleMeasureCombined_c
Remoteimplfiles for all remote Process Data types

Flexible usage for DIN 9684 and ISO 11783

The IsoAgLib handles Process Data to the greatest part independent from the underlying protocol. This allows to write applications, which concentrate only on the data communication part without the overhead of protocol specific details. This is achieved by the CAN data formating and low-level processing class __IsoAgLib::ProcessPkg_c, which detects dependend on the receiver ( for send of msg ) and/or sender ( for receive of msg ) and its protocol state, which protocol format to use. This is achieved by IsoAgLib::iSystemMgmt_c which provides functions to derive the protocol type of a ECU based on it GetyPos == device_type/_instance setting.

Conversion between old DIN 9684 Data Dictionary and new ISO 11783 Data Dictionary

It is planned to keep the Data Dictionary unique for both protocol variants, and to implement an internal mechanism which converts the ident code in and from messages to the right Data Dictionary type. But as this is a not yet finished work in the ISO 11783 working group, this feature can't be implemented yet.

Conversion between old DIN 9684 PD/MOD commands and ISO 11783 commands

In the hope, that the plans for the new Process Data handling in ISO 11783 are corrected in a way, that it provides at least the same capability as the old DIN 9684 style PD/MOD commands, the IsoAgLib is going provide a mechanism for a unique API in this area also. This means, that an application can simply use the several Process Data commands via the class member methods of the different Process Data class types without any notice of differences between the old DIN style PD/MOD and new style command field protocol.

Principles for the Use of Process Data

In spite to the first design of IsoAgLib ( version <= 0.3.0 ), the single variable instances of data type "Process Data XY" ( with XY from { IsoAgLib::iProcDataLocal_c, IsoAgLib::iProcDataRemote_c, IsoAgLib::iProcDataLocalSimpleMeasure_c, IsoAgLib::iProcDataRemoteSimpleSetpoint_c, ... } ) can be placed like a "normal" variable ( e.g. int, char ) in the program in the variable scope where the process data information shall be accessed. Like "normal" variables, pointers to a process data instance can be distributed round the application.

Important Note to the Use of Process Data Variables

Never assign a value from one process data instance to another and never use a process data type as function parameter.
Instead: Provide access to functions or different sub-programs by POINTER to a Process Data instance.
Reason: A Process Data type occupies a lot of RAM for the management of the different sub-data and a copy ( this is also done for function call without pointer or references ) of complete Process Data instances are very expensive oepration regarding to RAM and time.

Example for Creation and Correct Distribution of Process Data Variable

 // declare extern example function ( dummy )
 extern void doSomething( IsoAgLib::iProcDataLocal_c *pc_localProc );
 // set device type of local ECU: fertilizer
 IsoAgLib::GetyPos_c myGtp( 5, 0 );
 // initialise variable upon construction/definition
 // local process data for "on/off mechanical" [0/0x64] of fertilizer spreader (LIS=0, GETY=5, WERT=1, INST=0)
 // with full working width (ZAEHLNUM 0xFF), POS, GETY_POS of local data (can vary from previously given GETY and POS),
 // the pointer to myGtp helps automatic update of GETY_POS, mark this value as NOT cumulated (default)
 // load/store value in EEPROM at adress 0x1234
 IsoAgLib::iProcDataLocal_c c_myWorkState( 0, myGtp, 0x1, 0x0, 0xFF, 2, myGtp, &myGtp, false, 0x1234 );
 // set measurement data to working == 0x64
 c_myWorkState.setMasterVal( 0x64 );

 // alternate: initialise process data variable after definition
 // "working width" [mm] of fertilizer spreader (LIS=0, GETY=5, WERT=3, INST=1), store/load data at EEPROM adress 0x1238
 // use PRI = 2 ( target process data for DIN )
 IsoAgLib::iProcDataLocal_c c_myWorkWidth;
 c_myWorkWidth.init( 0, myGtp, 0x3, 0x1, 0xFF, 2, myGtp, &myGtp, false, 0x1238 );

 // call function doSomething -> give pointer to variable c_myWorkState -> transfer simple adress via stack
 doSomething( &c_myWorkState );

Example for Starting a Measure Program

The IsoAgLib provides a capable support for measuring programs, where an ECU can request the periodical send of a measurement value ( Process Data ) at a remote ECU. This can be performed by creating so-called subprogs ( >= 1 per measurement program ), where the conditions to trigger a measurement value send can be defined. The final start command for the measurement program can then select the values, which should be sent on each trigger event.
The nice on all this features is, that the ECU, which provides the data must only update the measurement value, as all the other communication is performed by the IsoAgLib ( i.e. register measure programs and handle send of data, ... ).
 // define device type of remote ECU ( from which we want measurement data )
 IsoAgLib::GetyPos_c remoteGtp( 1, 0 );
 // define remote process data to gather information of remote work state
 // use PRI = 2 ( target process data for DIN )
 IsoAgLib::iProcDataRemote_c c_remoteWorkState( 0, myGtp, 0x1, 0x0, 0xFF, 2, remoteGtp, &myGtp);
 // trigger value update every 1000 msec.
 c_remoteWorkState.prog().addSubprog(Proc_c::TimeProp, 1000);
 // start measure program: trigger send of current measure value ( and not MIN/MAX/AVG/ etc. )
 c_remoteWorkState.prog().start(Proc_c::Target, Proc_c::TimeProp, Proc_c::DoVal);
 while( true ) {
   // use last received measurement value
   if ( c_remoteWorkState.prog().val() == 0x64 ) {
     // do something if remote ECU is in work state

Enhanced Use of Process Data with call of Handler functions on Several Events

If an application has to immediately react on received setpoint or measurement update, it is needlessly time consuming to poll always for the awaited event. The IsoAgLib provides a mechanism to define a handler which can then be registered on all Process Data variables, which should use the handler.
Example usage: Define function which evaluates new received setpoints for immediate response and realisation ( if accepted ) in current control loop.
 // derive handler class frome base class of IsoAgLib
 class MyProcessDataHandler_c : public IsoAgLib::ProcessDataChangeHandler_c {
     // react on new received setpoint for local process data
     // (remote system which wants to control the local system dependend on the setpoint
     // sent a new setpoint value)
     // rc_src general event source class, which provides conversion functions to get needed event source class
     // ri32_val new value, which caused the event (for immediate access)
     // rc_callerGetyPos IsoAgLib::GetyPos of calling device - i.e. which sent new setpoint
     // return true -> handler class reacted on change event
     virtual bool processSetpointSet( EventSource_c rc_src, int32_t ri32_val, IsoAgLib::GetyPos_c rc_callerGetyPos, bool rb_changed );
 // implement the handler function, which is called on each received setpoint
 bool MyProcessDataHandler_c::processSetpointSet( EventSource_c rc_src, int32_t ri32_val, IsoAgLib::GetyPos_c rc_callerGetyPos, bool rb_changed ) {
 { // %e.g. check for device type of commanding ECU
   if ( rc_callerGetyPos.getGety() == 0x1 ) {
     // reaction on setpoints sent by device type 1
   else if ( abs( ri32_val - currentVal ) < 10 )
   { // handle setpoints which are near to current value...
 // define variable instance of the handler class type
 MyProcessDataHandler_c c_setpointHandler;

 // define local process data, which uses the handler
 IsoAgLib::iProcDataLocalSimpleSetpoint_c c_myFertilizerAmount;
 // init process data with pointer to handler, which shall be called upon setpoint receive
 c_myFertilizerAmount.init( 0, myGtp, 5, 0, 0xFF, 2, myGtp, &myGtp, false, 0x123A, &c_setpointHandler );

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