Dear readers,
My name is Sadashiv Balawad and I am working as Junior Software Engineer at Luxoft India. Luxoft gave me many opportunities to work on various projects, which inspired me to talk about the importance of Diagnostic Development with Autosar(Part-2)
Requirements Relating to a Tool Chain that Supports those
Processes
It must be possible to adapt tool chains used in the diagnostic development process to the above-mentioned scenarios. At the start of the process, it is necessary to define the diagnostic requirements in the Requirements Management System (RMS). From the diagnostic requirements, it is then possible to derive requirements for the application software and requirements for the associated diagnostic services. In general, the two types of requirements are implemented by different roles – in the form of software components as well as in the form of a suitable basic software configuration. They are then combined by the integrator
during ECU integration. This is exactly where the afore mentioned diagnostic mapping in DEXT comes into play. The overall process is illustrated in Figure 2.
Figure 2: Diagnostic technique between the OEM and Tier 1 provider
In a top-down process, the diagnostic application software is first developed, or existing software is re-used. The diagnostic input data is derived from the requirements and interface descriptions for the application software. This represents a major advantage compared to many existing processes in which the diagnostic data is adapted to the requirements and application software. This is often a very time-consuming manual harmonization task.At the same time the DEXT format is created, it is also necessary to create the ODX data. Generating ODX and DEXT data from a common source ensures that the diagnostic tester behavior matches the diagnostic software in the ECU
Example Based on a Tool Chain
Figure 3 illustrates the example of a tool chain for diagnostic development that meets these requirements using tools from Vector. It consists of the tools Prevision for requirements and system design, Candela Studio as the diagnostic authoring tool and DaVinci Configurator Pro for configuring the basic software. A diagnostic requirement is defined in Prevision at an early development stage. For example, this could be a requirement to provide an oil temperature sensor. For this sensor, the diagnostics should contain a service for reading the oil temperature, a service for overwriting the sensor value by means of I/O control as well as support for one or more possible DTCs that indicate a temperature sensor malfunction. The software component interfaces of the System Extract are derived from these requirements in arxml format. The software component interfaces also define the parameters for the diagnostic objects. In the example of the oil temperature sensor, a software component port provides the current temperature value and the port’s interface defines whether the measured value is a 16 or 32-bit value, together with the conversion formula and unit used. A software
component synchronization functionality specially developed for this workflow in Candela Studio then automatically uses this information to generate the appropriate diagnostic data for the following diagnostic elements:
Diagnostic Data Identifiers (DIDs) for Read, Write and
I/O-Control
Routine Control Identifiers (RIDs)
Events and DTCs
In our example, the diagnostic expert creates “ReadDataByIdentifier” diagnostic service in CANdelaStudio. This
contains a “Temperature” data element with an unsigned 16-bit value and a resolution of 0.1 Kelvin, a I/O-Control service with the same data element and a DTC indicating a sensor defect. The diagnostic expert also defines the identifier that is used to access the oil temperature in the diagnostic communication.
Additionally, CANdelaStudio stores the port at which the software component supplies the temperature and the diagnostic service that reads the data from this port. Using this statistics,CANdelaStudio is capable of export the DEXT format collectively with the diagnostic mapping. DaVinci Configurator Pro reads inside the DEXT layout and derives the configuration of the diagnostic basic software program modules from it. DaVinci Configurator Pro then generates the software component interface for the diagnostic basic software modules and connects it to the ports of the application software components – in a way which is compatible with the diagnostic mappings in the AUTOSAR DEXT.
Figure 2: Diagnostic workflow primarily based on the instance of a Vector device chain
Conclusion
The AUTOSAR Diagnostic Extract opens new possibilities in the field of diagnostic development. From the precise description of the data, including the derivation of the basic software configuration, through the distributed development of diagnostics at the OEM and Tier 1 supplier through to a top-down approach to the automatic integration of the diagnostic functions in the ECU. The Vector tool chain uses these capabilities and simultaneously ensures the synchronization of the ODX and DEXT data. AUTOSAR DEXT is used in both AUTOSAR platforms: initially developed for AUTOSAR Classic, it is also the only diagnostic description format in AUTOSAR Adaptive. The presented method can therefore also be used for the AUTOSAR Adaptive platform based development
Thank you
Top comments (0)