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

Overview on Structure of IsoAgLib

The core components of the ISOAgLib which are licensed under the conditions of the LGPL license of the Free Software Foundation are placed in the directory <lgpl_src> . Please note that the license requires each user to provide public access to each change of the files within this core directory. As the maintainers of this library will collect and incorporate all contributions. This process guarantees that each contributor will get more than he personally provided.
The main contributors to this project are in order of the importance of their part:
  1. Deutsche Forschungsgesellschaft ( DFG ) by funding the research project IKB-Dürnast
  2. Research Group of Professor Auernhammer by running the research project IKB-Dürnast
  3. Fritzmeier by contribution of the development of the ISO 11783 Virutal Terminal framework which was needed for the user interface of their product Chlorophyll Sensor MiniVeg N
  4. Sensortechnik Wiedemann (STW) by support for the research of the main author within his research for IKB-Dürnast

Overview on Directory Structure of LGPL Licensed Parts of IsoAgLib

The structure of the source files of the ISOAgLib is described in the following imagemap diagram. The informaiton "(partly) obligtory, optional" is normally true for all contained directories and files of the listed nodes, as long as no exception is listed in the diagram.

Structure of Main Parts

inline_dotgraph_8

Structure of Supplementary Parts

inline_dotgraph_9

Principles of Structuring the IsoAgLib

Distribution of Core Components and Supplements

The ISOAgLib was developed for a research project, where an ECU should detect automatically connected implementes and should then record the retrieveable information on a PCMCIA memory card ( connected via RS232 ). Additionally some information were read from digital and analog input sensors.

Thus the ISOAgLib had not only the target to implement the DIN 9684 and ISO 11783 protocol, but also to provide a platform hardware independend API for capable hardware access. A ruling target of ISOAgLib is to server optionally as a complete hardware extension layer, which allows the application developer to use driver services which are not included in the standard platform libraries and which introduce no platform dependency on the main project. This principle is used for the actively used research systems and for the commercial development on the implement Chlorophyll Sensor MiniVeg N.

But as most projects will start with ISOAgLib as pure ISO 11783 or DIN 9684 implementation, all supplementary parts can be simply excluded from project - by just not including in project file list ( and not calling methods from the excluded files - ;-) ). This results in the main directories <lgpl_src/IsoAgLib> and <lgpl_src/supplementary_driver>.

But not all files are obligatory for each ISO 11783 or DIN 9684 project - as described in the diagram above. First of all, you can exclude complete protocol features by exclusion of their corresponding directories. Secondly some main features like System Management ( claim address for local identities, monitor lists of all network nodes ) or process data contains some options, which are not needed for all projects. This could be ruled by the decision for the protocol ISO 11783 OR DIN 9684, or by the feature depth of the used process data. Please lool at the documentation of the coomunication parts, where more information on optional parts is provided.

Grouping of Interface with corresponding Implementation

The ISOAgLib provides all application relevant classes, functions and other components in the namespace IsoAgLib, and hides the implementation of these components in the namespace __IsoAgLib. The name of all interface classes starts with a lower 'i', whereas the corresponding implementation class has the same name - without the 'i' at the beginning. The implementation classes and source files are also hided within the subdirectory /impl of the respective directory - e.g. <lgpl_src/IsoAgLib/util> for interface and <lgpl_src/IsoAgLib/util/impl> for implementation. So the content for the several "/impl" subdirectories is really only meant for experts who want to know how the different functions are implemented - e.g. for impelmentation of extensions and bug-fixes.

Structure of the HAL

The platform dependend variants of the HAL are grouped by the name of the respective plateform. This name is defined in the central configuration file isoaglib_config.h , where either the corresponding #define like SYSTEM_ESX can be constantly defined or can be provided as runtime Defines during the Make-Process ( as compiler option ). The conditional #ifdef rules in isoaglib_config.h allow the headers of the ISOAgLib to fetch the corresponding headers from the central headers in the directories <lgpl_src/IsoAgLib/hal> and <lgpl_src/supplementary_driver/hal>. Each platform has its own subdirectory in the previous mentioned directories. Like described in the diagram at the top of this page, each driver extension directory is mapped with a same named directory within <lgpl_src/IsoAgLib/hal/PlatformXY> or <lgpl_src/supplementary_driver/hal/PlatformXY>.

The main idea of the HAL is to provide a unique API for hardware and system acces where at least the used functions have a unique name and functions ( described by their parameters ). This can be realized in most cases by simple inline functions - which are a better C++ variant of the old style function-makros of C. The call of these inline functions is replaced during compile time by their function body - thus the platform library functions are directly called during runtime. If the ISOAgLib requires some features which can't be provided by simple inline functions, the needed additional functionality can be implemented in the files named like system_target_extensions.h and system_target_extensions.cc .

The name mapping is provided also with the help of namespaces, which cause no runtime overhead. Therefore the needed platform specific headers are included with an extern "C" statement in the namespace __HAL. The inline functions are defined as part of the namespace HAL, so that the names of the platform specific headers and the HAL can be identically. The compiler can distinguish between them with the help of the namespace.


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