Image Processing Reference
In-Depth Information
models.hefunctionalmodel,i.e.,thefunctionstobeexecutedbythedistributedsystem,isprimarily
independent of a specific car model and can be reused in different model ranges. The architectural
model on the other hand, i.e., the concrete number of ECUs and their properties in a certain car, vary
between model ranges.
It is decisive for a useful development process to allow the separate development of the functional
model and the architectural model. At the same time the process must support the mapping of the
functions to a concrete hardware architecture. he DECOMSYS OEM-supplier development process
meets this requirement.
16.5 Standard Software Components
Standard software components within an ECU deliver a set of services to the actual application. he
application itself can make use of these services without implementing any of them. For example, if
a transport layer is part of the standard software components used in a project, the application does
not need to take into account the segmentation and reassembly of data that exceed the maximum
message size.
In order to reuse the application code in another project, the services offered by the standard soft-
ware in the new project should be the same. If the standard software provides less functionality, the
code has to be changed, as missing services have to be added.
In the optimal case the standardization effort covers all OEMs and suppliers. Only then reuse of
existing code can be guaranteed, thus creating a win-win situation for all participants: The OEMs
can purchase tested software that has proven its function and reliability in other projects—suppliers
on the other hand have the possibility to sell this software, which they have created with considerable
effort, to other OEMs.
16.5.1 Standardized Interfaces
Standard software components are not the only answer to the challenge of reuse. he standard soft-
ware components and their standardized services must be complemented by standardized interfaces,
through which the application software can access these services. Standardizing interfaces for soft-
ware means to provide one operating system API for the software to access communication as well
as other resources like ADCs. Similarly, standardized network interfaces allow the reuse of entire
ECUs in different networks. he hardware of a distributed system can have a standardized interface
represented by an abstract description of the network communication.
Standardization of software components as well as interfaces and thus a system architecture is
not a competitive issue. Depending on where the interfaces are set, there is ample room for each
participating company to use its strengths effectively to achieve its purpose. In our opinion, the real
competitive issues are the functions in an ECU or the overall system functionality that is realized
by the interaction of ECU functions. he special behavior of an electronic power-steering system as
perceived by the car driver is mainly determined by the control algorithms and their application data,
rather than by the type of communication interface used for integration.
With respect to standardization efforts, the industry is currently moving in the right direc-
tion. Initiatives like the open systems and the corresponding interfaces for automotive electronics
(OSEK/VDX) Consortium [], HIS [], and many others attempt to standardize certain software
components and interfaces. The field bus data exchange format (FIBEX) group that is now part of
the Association for standardisation of automation and measuring systems (ASAM) Consortium []
develops a standardized exchange format between tools based on XML, which is able to hold the
complete specification of a distributed system. Many of these initiatives and projects are now united
 
Search WWH ::




Custom Search