Reprinted from Technical Papers on the Development of Embedded Electronics
Here I would like to highlight some of the most interesting ideas from the set of articles by Vector. This is 4 of 7 posts on this topic.
The Standard Mix does it: Diagnostics with AUTOSAR and ODX
The Open Diagnostic data eXchange (ODX) format is an XML-based data format for describing the data relevant to vehicle diagnostics. ODX was conceptualized as an open format for exchanging diagnostic data between automotive OEMs and their suppliers. AUTOSAR is the future-oriented reference architecture for ECU software. Clearly specified interfaces, standardized behavior and XML-based data formats are key features of the AUTOSAR standard. This is the second article of the “Diagnostics with AUTOSAR and ODX” series, and it addresses the topic of ODX and how available ODX data can be profitably integrated in AUTOSAR development.
From Diagnostic Requirements to Communication
Standardization is the Trend in the Development of Automotive Electronics
A key aim of open architectures, configurable components and harmonized exchange formats is to let developers focus more on the development and reuse of innovative and product differentiating functions. In recent years, a number of independent standards have been created, all of which have affected processes and tools for diagnostic development – in particular ODX and AUTOSAR. At the same time, the systematic capture, management and tracking of requirements took hold, which also had a significant impact on processes, methods and tools. Is it possible to do without one or more standards? Is there a super-standard? Or can the standards and methods be combined with one another effectively and efficiently?
The development of a system starts with the requirements from the user’s perspective. The capture of requirements marks the beginning of an iterative process (Figure 1), in which requirements of a system are progressively made more specific and precise. If the solution space for fulfilling requirements is still large, the later specification describes individual subsystems precisely and without ambiguities.
In practice, requirements differ in terms of how specific and precise they are. Text-based requirements describe a system property to be fulfilled in text form, usually incompletely and purposely fuzzy, phrased or just in note form. Specification requirements, on the other hand, are precise and not only describe the requirement itself, rather they also include the solution and leave very little freedom for the specification. Formal languages are often used for the description, which are appended to text-based requirements in files. Reference requirements contain a reference to a specification, e.g. “as in the previous system”. Technically, these reference requirements actually reference specifications in other databases or data management systems in many cases.
Ideally, requirements are defined as precisely as possible from the start, but only as specifically as necessary. Unclear or ambiguous requirements lead to considerably increased effort over the course of the development process, because clarification means there is a need for additional coordination, and it often results in a specification change. In the least favorable case, the system implementation may even need to be modified. On the other hand, requirements that are unnecessarily specific can often actually obstruct the path to the quickest and most cost effective solution. If aspects of a solution path are intermixed with requirements early on, this unnecessarily reduces the solution space. Often, this also eliminates the opportunity for re-use.
Especially when requirements change over the course of development, it is important to separate the substantial requirements from relicts of earlier solution approaches.
During development, the totality of implementation progress for all requirements offers a good overview of the implementation progress of the total system or of a subsystem (maturity level tracking).
If you want to systematically exploit the advantages of a requirements-driven process, then the process described above must be applied to all subsystems, including those of different development disciplines that are actually independent. Naturally, this also applies to diagnostics.
Today, spreadsheet-oriented tools and databases are usually used to manage requirements. Here, requirements are either not described formally, or they are only described formally in part. These tools must be flexible enough to capture and track all requirements – even those that are very fuzzy.
Regarding the specification, various other tools have become established in the various disciplines, e.g. modeling and authoring tools, which usually generate a formal specification. In contrast to user requirements, precise definition of the content is the primary goal and not flexibility, and this fundamental difference results in different, specialized tools. Consequently, classic requirement management tools can only be used meaningfully up to a certain level of detail. This also applies to diagnostics.
Standardized exchange formats are specially designed for a specific discipline. ODX, for example, specifies data that is relevant to the diagnostic tester. Exchange formats usually use a formal data model that assures a consistent specification that is complete in its details. On the other hand, these formats are too restrictive for formulating fuzzy requirements. Classic requirement management tools are well-suited to describing text-based diagnostic requirements. The standardized data exchange format ODX, meanwhile, would be unsuitable for describing or exchanging these text-based requirements, because it is too formal and precise.
Today, AUTOSAR (AUTomotive Open System ARchitecture) is the reference architecture for ECU software in the automotive industry. AUTOSAR standardizes the description of individual component or vehicle functions and the description of the overall system.
The diagnostic software in AUTOSAR consists of the three basic software modules DCM, DEM and FIM.
The DCM (Diagnostic Communication Manager) implements diagnostic communications according to UDS and OBDII. The DEM (Diagnostic Event Manager) implements a fault memory and manages fault status and supplemental information on fault symptoms. In the case of active faults, the FIM (Function Inhibition Manager) prevents execution of certain functions and suppresses secondary errors.
DCM, DEM and FIM are configured by the ECU Configuration Description (ECUC). Their contents are best understood by illustrating how requirements relate to the configuration of software components.