Tiêu chuẩn iso 22900 3 2012

Reference number ISO 22900-3:2012ESecond edition 2012-12-01 Road vehicles — Modular vehicle communication interface MVCI — Partie 3: Interface pour la programmation des applications du

Terms and definitions

For the purposes of this document, the following terms and definitions apply

AccessKey path identifier through the inheritance hierarchy as defined in ISO 22901-1 ODX to a diagnostic data element

Copyright International Organization for Standardization

3.1.2 ancestor object parent object located above in the object hierarchy with respect to a given object

3.1.3 descendant object child object object, located below in the object hierarchy with respect to a given object

FlashJob new class derived from MCDJob which is used to start FlashSessions within the MVCI diagnostic server

This information is sourced from the databases During runtime, the FlashSession can be configured by this service, with only one session allowed per job The application can retrieve the priority assigned to each FlashSession in the database and organize the sessions based on this priority.

The job interface of flash jobs (MCDFlashJob) extends the job interface of normal diagnostic jobs (MCDSingleECUJob) by a session object, i.e its method prototype is extended as follows:

FlashKey unique identification for a flash session

FlashSessionClass user-defined collection of FlashSessions, which can be used to separate FlashSessions for different tasks (e.g sessions for data, sessions for boot, or sessions for code and data)

FlashSession smallest unit that can be flashed separately by the MVCI diagnostic server, and which may consist of several data blocks

3.1.8 functional class set of diagnostic services

3.1.9 function dictionary hierarchical function catalog to organize external test equipment user interfaces (available at MCDDbProject):

 references to one or several ECUs and their diagnostic data content relevant for that function;

 references to services/jobs to make functions “executable”;

 definition of function input and output parameters with optional references to parameters of related services

3.1.10 interface connector connector at the vehicle’s end of the interface cable between the vehicle and the communication device

3.1.11 job sequence of diagnostic services and other jobs with a control flow

3.1.12 location set of diagnostic data valid on a given hierarchical level of inheritance according to ISO 22901-1 ODX

NOTE The following locations exist:

Logical Link set of data, identifying the physical line, the interface and protocol used for an ECU

3.1.14 physical interface link physical connection between the VCI connector of a VCI and the interface connector

3.1.15 physical link physical vehicle link connected to a physical interface link, so it is the connection from the interface of the diagnostic server to the ECU in the vehicle

3.1.16 physical vehicle link unique bus system in a vehicle, so it is the connection between the vehicle connector and the ECU

3.1.17 priority term used by test systems to decide in which order the sessions have to be flashed

3.1.18 project pool of diagnostic data

NOTE References between such data are resolvable inside this same project

ECU sub functionality or components

EXAMPLE LIN-slaves (available at MCDDbLocation)

3.1.20 vehicle connector connector on a vehicle providing access to the bus systems in the vehicle

Symbols

Figure 1 shows the legend of hierarchical models

``,,,``,,`,```,,,,`,```,```,,,-`-`,,`,,`,`,,` - color print black/white print green dark grey green dark grey white white yellow grey blue black yellow grey

Figure 1 — Legend of hierarchical models

Abbreviated terms

ASAM Association for Standardisation of Automation and Measuring Systems

ASCII American Standard for Character Information Interchange

COM/DCOM Distributed Component Object Model

CORBA Common Object Request Broker Architecture

DoCAN Diagnostic communication over CAN

DOP diagnostic Data Object Property

DoIP Diagnostic Over Internet Protocol

ECU MEM Electronic Control Unit MEMory

JAVA RMI JAVA Remote Method Invocation

MVCI Modular Vehicle Communication Interface

ODX Open Diagnostic data eXchange

VIS Variant Identification and Selection

General

This part of ISO 22900 is based on the conventions discussed in the OSI Service Conventions (ISO/IEC 10731:1994) as they apply for diagnostic services.

Typographical conventions and mnemonics

Normal text of the specification is presented like this

Source code and technical artifacts within the text are presented like this

Diagrams that denote interaction sequences, relationships or dependencies between interfaces are presented using the Unified Modeling Language’s (UML) convention

The name of each interface and each class defined by this part of ISO 22900 shall use the prefix of the stereotype, e.g “D”

The leading letter of each method and each parameter is small

The leading word of each method shall be a verb

The letter “_” is not allowed in interface names, method names and parameter names, but it is allowed for constants

The leading letter of each constant is “e” and behind this the name is written in capital letters

ODX element names are written in upper cases, e.g SHORT-NAME MVCI diagnostic server Names are written in mixed fixed, e.g MCDDbProject.

Sequence diagrams

With the help of Sequence Diagrams the interactive use of the API and the sequences for certain general cases are presented in chronological order

Sequence diagrams in UML are organized to present a chronological flow from top to bottom The left margin features a commentary column that describes individual activities The Client application is positioned on the left side of the diagram, with the EventHandler included when relevant On the right side, the necessary API objects for the specific case are displayed, either alongside or without the EventHandler.

If necessary, the MVCI diagnostic server is presented at the right, outside

Only relevant API objects for the specific time instance are displayed, rather than all possible objects The vertical thin line indicates the object's life line, while the broader sections along it represent the object's activities.

The black horizontal arrows indicate the actions required between the Client and the MVCI diagnostic server, with the target object executing the specified action Meanwhile, the grey horizontal arrows signify the return of objects.

Stereotypes

Stereotypes are abbreviation characters which are used in MVCI diagnostic servers to mark the affiliation of statements, interfaces and methods to one of the possible parts

Table 1 defines the stereotypes which are used in MVCI diagnostic servers

Table 1 — Stereotypes Stereotype Usage of method and class is in following Function Blocks allowed

Measurement, Calibration and Diagnostic

Methods with this stereotype can only be used inside of Diagnostic Job These methods are not available for use at the API

The specification release version of this part of ISO 22900 is: 3.0.0

6 Structure of a MVCI diagnostic server

Figure 2 shows the architecture of an MVCI diagnostic server

Data Processor Flash Data Processor Job Processor

Communication Services GDI, COM/DCOM, Java RMI, C++

Communication Services MCD-3 D Object Model

Protocol Module MVCI Software any diagnosis protocol

Figure 2 — Architecture of an MVCI diagnostic server

With the help of a server the control units are optimally adapted to the relevant requirements for their use in vehicles This procedure is often referred to as “Applying”

The following features (interfaces and methods) are optional:

 the concept of System generated Vehicle Information table

Optional features in a model indicate that both the runtime and database components do not need to be implemented by a diagnostic server that lacks the specific feature When a client application invokes a method associated with an optional feature, the diagnostic server should return an empty collection if the method's return type is derived from MCDCollection If the return type is different, the method call should result in an MCDSystemException of type eSYSTEM_METHOD_NOT_SUPPORTED It is essential that any supported optional features are fully implemented, and a comprehensive list of methods related to these optional functionalities is available.

The increasing number of control units in vehicles enhances diagnostic capabilities, which are accessible to the server through control unit description files.

The control unit description files provide a manufacturer-independent data exchange format, enabling any server to process the data contained within This format encompasses all configuration data for the diagnostic server, internal data of ECUs or ECU networks, and the associated communication methods.

ECU access are stored in the ODX database This database is server and operating system independent and therefore allows data to be exchanged between vehicle manufacturers and ECU suppliers

An application can extract all necessary data from the database to operate the MVCI diagnostic server, ensuring that only the MVCI diagnostic server has access to the information contained in the individual control unit description files within the database This process maintains the consistency of the information across the system.

AUSY and MVCI diagnostic server is guaranteed

Also, a decoupling from the used data description exchange format (XML) takes place

The MVCI diagnostic server is responsible for managing a shared database that supplies essential information for all MVCI diagnostic server objects This database is not limited to a single object; rather, it is accessible throughout the entire diagnostic server The organization and allocation of objects or references are handled specifically by the implementation of the diagnostic server.

The object model is designed for Single Client Systems, ensuring ease of use for this common application scenario In this model, individual objects do not contain client references; instead, the management of these references is handled by the diagnostic server, requiring a tailored implementation approach.

The object model has been designed in a technology and programming language independent way It may be used remotely as well as locally

The MVCI diagnostic server's object model facilitates the integration of these servers with automation systems, allowing for remote control in test stands This model standardizes functionality through defined interfaces and methods Effective communication relies on the specific implementation of the object model tailored to the platform, programming language, and linking mechanisms in use.

Among others the following are realized:

The necessary specifications for this will be described and published in separate documents For this process design patterns and mapping rules are defined and published

All other specifications will be set up and realized implementation specifically by the respective system provider

Within the function block diagnostic a breaking down into characteristic sub tasks will take place, which are shown in the following:

The Communication Processor plays a crucial role in generating and analyzing request and response telegrams to Electronic Control Units (ECUs) It manages all protocol-specific functions, including timing, protocol header creation, and checksum calculations Currently, the specification of diagnostic protocols is not under ASAM's purview, as it falls within the scope of ISO standards such as ISO 14230-3 KWP 2000, ISO 14229 UDS, and ISO 15765 DoCAN Importantly, the Communication Processor must be configured using Communication Parameters, serving as the sole interface to the ECU.

The Data Processor plays a crucial role in supplying parameters and results at a physical level, fetching essential information from the database It converts ECU responses between hexadecimal and physical or text representations, serving as the sole interface to the ODX database Additionally, the Data Processor provides an ODX library to the Job Processor and manages Jobs stored within the ODX database.

The Flash Data Processor plays a crucial role in loading programs and data into ECUs, serving as the sole interface to flash data It provides access to the ASAM MCD2-ECU-MEM, which includes comprehensive information on the physical and logical layout of data and code, as well as various combinations of data and code segments Additionally, the Flash Data Processor offers a flash library (flash object) to the Job Processor, enhancing its functionality.

The Job Processor is responsible for the execution of service sequences and only uses objects of the ASAM

The MVCI diagnostic server API allows access to all processors through the Job Processor, which is integral to the database and operates on the ODX format It offers several libraries for standardized interaction with the Communication Processor, Data Processor, Flash Data Processor, and itself To ensure consistency, the Job Processor utilizes the same objects for communication with various processors, aligning with the ASAM MVCI diagnostic server API Additionally, the Job Processor retrieves executable code from the Data Processor, which reads the ODX database file.

MCD system object

The server interface serves as the initial access point for clients to the MVCI diagnostic server, allowing them to reach all other interfaces Each client is assigned a unique MCDSystem object, which implements the MCDSystem interface, while all clients operate on the same project and database Access to a specific section of the database is granted upon project selection, and attempting to select another project simultaneously will result in an exception.

Figure 3 shows the system scheduling

Communication Processor Data Processor Flash Data Processor Job Processor

The diagrams specified in this part of ISO 22900 always refer to the representation within the client and are not designed for MultiClient scenarios.

Description of terms

This section provides detailed explanations of key terms, with brief definitions included in 3.1 Each term directly associated with an ISO 22901-1 ODX element is accompanied by its corresponding ODX element name in parentheses.

By means of the AccessKey, the access position within the inheritance hierarchy of the ODX diag layers is identified

An AccessKey consists of an ElementIdentifier, which is enclosed in square brackets, followed by the short name of the element instance Essentially, an AccessKey is a series of tuples made up of ElementIdentifiers and their corresponding short names The permissible combinations of ElementIdentifiers are specified by the Locations, and each AccessKey is unique within a single database.

For every element accessed via an AccessKey there is a LongName and a Description LongName and Description shall be in UNICODE

Functional classes are user-defined groups of services that can include multiple services, although each service can only have one specific meaning.

7.2.4 Job (SINGLE-ECU-JOB, MULTIPLE-ECU-JOB)

The sequence of diagnostic services and tasks is guided by the control flow based on the results obtained Key use cases for these jobs include ECU (re)programming, encryption of the seed key algorithm, and gateway testing.

A Location represents a hierarchical level for diagnostic Services

The following locations are permitted:

The location is the access point to data base specific definitions (meta information) , e.g available Services, DiagComPrimitives, CompuMethods

Figure 4 shows the location hierarchy of ASAM MCD database

Figure 4 — Location hierarchy of ASAM MCD database

Each Location is addressed by means of an AccesKey The following AccessKeys of possible Locations in the hierarchical system are allowed:

 [Protocol]Instancename.[EcuBaseVariant]Instancename.[EcuVariant]Instancename

Figure 5 shows the AccessKey example

 [Protocol]UDS.[EcuBaseVariant]DoorLeft.[EcuVariant]DoorLeftStep1,

 [Protocol]UDS.[EcuBaseVariant]DoorLeft.[EcuVariant]DoorLeftStep2,

A Logical Link refers to the connection to Electronic Control Units (ECUs), typically involving a single ECU, but can include multiple ECUs in a Functional Group Each Logical Link is identified by a short name and detailed in the Logical Link Table, which includes elements such as the AccessKey and the Physical Vehicle Link or Interface These links facilitate access to the same ECU through various methods or allow access to multiple instances of an ECU across different links For further information, please refer to Clause 8.

A Physical Interface Link serves as a logical connection between the MVCI diagnostic server and the Interface Connector, identified by a short name Details regarding the Physical Interface Link are found in the Interface Connector Information Table, which also includes descriptions of the Interface Connector The available Physical Interface Links are determined by the interfaces present in the MVCI diagnostic server.

The Interface Connector Information Table has an entry for each Physical Interface Link and one connector for this Link

A physical Link refers to a Physical Vehicle Link that connects to a Physical Interface Link, establishing the connection between the MVCI diagnostic server's interface and the vehicle's ECU.

Figure 6 shows the overall scheme between different links and tables in D

Interface Connector Interface Connector Pin

MVCI Protocol Module Connector Pin

Figure 6 — Overall scheme between different links and tables in D

The pins of the Vehicle Connector are connected to identical pins of the Interface connector

7.2.9 Physical Vehicle Link (PHYSICAL-VEHICLE-LINK)

The physical vehicle link refers to the specialized bus system within a vehicle, serving as the connection between the vehicle connector and the ECU This link is identified by a short name, and detailed information about it can be found in the Vehicle Connector Information Table, which includes essential data regarding the vehicle connector.

The Vehicle Connector Information Table has an entry for each Physical Vehicle Link and one or more Vehicle Connectors (Pins) for this Link

The available Physical vehicle links are defined by the vehicle

A project serves as a logical grouping for user-defined test installations, encompassing all necessary information for each installation Users are restricted to working within a single project, which must be logically organized (for instance, including two model series within one project) Consequently, the project tuple is excluded from the AccessKey.

At project level, the forming of manufacturer-specific hierarchies is possible, as for this level no standardization takes place

 all static database information (Diagnosis Services, ),

In the MVCI diagnostic server, users must first select a project from the available list before accessing any database information, ensuring that only one project remains active at a time.

The database of a project is not restricted to a physical file.

Version information retrieval

The method MCDSystem::getASAMMCDVersion():MCDVersion returns the ASAM release number of the interface For this specification it is the major value 3 and the minor value 0 defined

The method MCDSystem::getVersion():MCDVersion returns the tool version

The technology version number is available via the interface

The model version number and the reference implementations' version number are kept in sync, with the "interface number (IFN)" serving as the build number for reference implementations Each implementation has its own interface number, which is incremented continuously within a minor version whenever a new implementation is generated and shipped This interface number resets to zero with each new minor or major version and is independent of the version numbers, while the technology version number is incremented separately for each technology.

States of the MCD system

In the eINITIALIZED state, the MCDSystem object is sent to the client by the MVCI diagnostic server, allowing for the listing of database project descriptions and the execution of general system initializations.

Upon selecting a project, the system enters the ePROJECT_SELECTED state, allowing for database information retrieval while prohibiting any communication with the hardware.

Once the first Logical Link is established, the MCDSystem object transitions to the eLOGICALLY_CONNECTED state, enabling communication through the created Logical Links If the last Logical Link is removed from the runtime project, the system reverts to the ePROJECT_SELECTED state The deselectProject() function resets the MCDSystem object to its initial eINITIALIZED state.

The diagnostic server transitions to the eDBPROJECT_CONFIGURATION state by loading a database project at the MCDDbProjectConfiguration object, enabling database searches and configuration adjustments In this state, users can add or remove elements, including ECU-MEMs, which are essential for flashing ECU-MEMs can be temporarily loaded into an MCDDbProject or permanently integrated into a project configuration.

CONNECTED selectProject selectProject close remove load add load add deselectProject START

STOP first createLogicalLink last removeLogicalLink

1 'load' or 'add' of DbProject includes an implicit close of actual opened DbProject.

It has to be distinguished between the states of clients and the central state of the server (internal MCDSystem)

On the server side, there can only be one state at a time, which includes eINITIALIZED, eDBPROJECT_CONFIGURATION, ePROJECT_SELECTED, and eLOGICALLY_CONNECTED Once a client successfully invokes the selectProject function, the internal MCDSystem transitions to the ePROJECT_SELECTED state.

Table 3 defines the system states

The system state transitions for MCDDbVehicleInformation include various actions such as selecting and deselecting projects and vehicle information The state eINITIALIZED does not occur, while ePROJECT_SELECTED and eLOGICALLY_CONNECTED indicate valid selections However, the action eDB_PROJECT_CONFIGURATION is only valid if no conflicting vehicle information has been selected; otherwise, it results in an exception For detailed behavior, refer to the corresponding method definitions.

Figure 8 shows the system lock states eLOCKED_BY_THIS_

1 this transition can only be done in system state eINITIALIZED

The MCDSystem object can be exclusively locked by the client application for the entire MVCI diagnostic server, but this locking can only occur when the system is in the eINITIALIZED state During this time, the internal server MCDSystem object is inaccessible to other clients, preventing any communication with the diagnostic server.

In the states ePROJECT_SELECTED, eLOGICALLY_CONNECTED, and ePROJECT_CONFIGURATION, exclusive locking of an MCDSystem Object is prohibited When an MCDSystem Object is exclusively locked, only the locking client can access the MVCI diagnostic server, while all clients will receive system event notifications regarding the locking and unlocking status.

MCDProject/MCDSystem LongName and Description are server-specific values and can be empty An exception will not be used.

State changes

Methods designed to change a state must consistently exhibit the same behavior; specifically, if a transition to an available state is requested, the method should throw an exception without altering the state.

This behaviour is used by MCDSystem, MCDLogicalLink, MCDDiagComPrimitive

If any exception occurs during a state changing operation, the state shall not be changed.

Project configuration

In the ePROJECT_CONFIGURATION state of the MCDSystem, users can load and browse a database project, but cannot create runtime objects Transitioning to this state requires closing the current database project or selecting a runtime project, which automatically saves any changes made Users can switch to a different database project by loading or creating a new one, with the previous project being saved if modifications were made.

The Method MCDSystem:getDbProjectConfiguration returns a MCDProjectConfiguration Object, which can be used for

 browsing (without existing RunTimeObjects, MCD: MCDProjectConfiguration:load) and

 modification (D: MCDDbProject:loadNewECUMem) of DbProjects

The state transition from eINITIALIZED to ePROJECT_CONFIGURATION takes place only after a Client opens a DbProject by means of add/load

 MCDDbProjectConfiguration::getAdditionalEcuMemNames check the consistence of data read from the database An error of type eDB_INCONSISTENT_DATABASE should be thrown when inconsistent data has been identified

Figure 9 shows the project configuration

The MC DS system provides various functionalities for managing projects and interfaces Key methods include selecting a project, detecting interfaces, and retrieving active project details Users can access the current interfaces, database project configurations, and descriptions The system also allows for property management, including getting and setting properties, as well as handling server types and states Additionally, it supports event handling and interface preparation, ensuring seamless interaction with connected components The system is designed to manage versioning and compatibility, with methods to check for unsupported parameters and lock or unlock server access as needed.

MC D D bP rojectC on figur at ion > clo se () > getAc tiveD bP roject() > g etA dditio n alEC U M E M N ame s( ) > load()

The MCD Project involves creating logical links through various methods, including access keys, interfaces, and resource names It encompasses functions such as creating monitoring links, deselecting vehicle information, executing control commands, and retrieving active database vehicle information Additionally, it includes operations for getting clamp states, database project details, and control names, as well as removing logical and monitoring links The project also allows for selecting database vehicle information by name.

The MCD project provides access to various database variants and ECU memory functions It includes methods to retrieve access keys, functional groups, and function dictionaries Additionally, it allows for the retrieval of multiple ECU job locations and physical vehicle link or interface data The project also supports fetching protocol locations and vehicle information, along with a versioning function to load new ECU memory.

Interface structure of server API

Figure 10 shows the hierarchical model of a diagnostic server part I

Figure 10 — Hierarchical model of a diagnostic server part I

Figure 11 shows the hierarchical model of a diagnostic server part II

Figure 11 — Hierarchical model of a diagnostic server part II

Figure 12 shows the hierarchical model of a diagnostic server part III

Figure 12 — Hierarchical model of a diagnostic server part III

Figure 13 shows the hierarchical model of a diagnostic server part IV

Figure 13 — Hierarchical model of a diagnostic server part IV

All database interfaces originate from MCDObject, while all database collections stem from MCDNamedCollection Typically, runtime interfaces are directly derived from MCDObject Collections, exceptions, and named objects serve as fundamental classes for more detailed structuring In addition to MCDSystem and MCDProject, all database interfaces are categorized under NamedObjects.

The MCDEventHandler is an exception to the classification, not derived from MCDObject It facilitates communication between the diagnostic server and the Client, offering Callback methods for event transmission.

The MCDEnumValue serves as the superclass for all enumeration classes within this API, offering two methods for converting between the object and its string representation This design allows for efficient handling of enumerations on the server side using a hash map, eliminating the need to send string values to the API unless necessary.

The model is divided into two main components: the database, represented in yellow (black/white in light), and the runtime, shown in green (black/white in dark) The database is a fixed element that serves as the foundation for creating most runtime objects Classes associated with the database include the substring "Db" in their names, indicating their connection to data files such as ODX and Flash Data These "Db" objects are immutable, static, and exist as single instances, ensuring they cannot be altered by client applications.

All access is done by methods of the interfaces There are no attributes except in the classes which should behave like an enumeration

The API's object-oriented model is divided into communication (runtime) and database components, ensuring a data set with minimal redundancy and a streamlined communication layer.

The database encompasses all information detected from ODX and relevant environmental settings for the API To prevent unnecessary redundancies, each created object exists only once within the database, allowing communication objects to reference these database objects without duplicating information.

Database objects are static and lack an internal status, meaning that once created, their information cannot be altered by the Client or MVCI diagnostic server Upon project selection, all information becomes accessible, even if it is not currently present within the objects However, access to this information must be ensured within an acceptable timeframe.

The access to database objects is realized optionally via the short name of the object or via iteration within the database structure

The diagnostic server should generate suitable shortnames, as shortnames are not obtainable from ODX These shortnames should have a prefix “#RtGen_” that uniquely classifies them as generated

Figure 14 shows the project associations

1 ac tiv e D bV eh icl eIn for ma tio n

The MCDSystem serves as the entry object and runtime object, facilitating the creation of a runtime project based on its database project By selecting the Vehicle Information Table, users gain access to all database Logical Links, which are essential for establishing runtime Logical Links necessary for executing all runtime activities.

The communication component encompasses all interfaces used for interaction with the ECUs Most runtime objects are derived from database objects, establishing a direct link to them Some objects that implement communication interfaces are unique (singletons), while others can be instantiated multiple times The multiple instances of a single database object can have different parameters.

The runtime objects may be executed (executable), have an internal status and return results

Table 4 defines the overview RunTimeObjects

Table 4 — Overview RunTimeObjects Unique runtime objects /singletons Multiple runtime objects

MCDProject All derived from MCDDiagComPrimitive

The Object Model allows for polling a uniquely structured database, ensuring that each element is available only once to eliminate redundancies Connections between individual database elements can be accessed through specific methods, which return either instances or references.

All database interfaces have methods for the polling of ShortName, LongName and Description

A more detailed description can be found with the description of the hierarchic model and the Entity Relationship diagrams

Database information may be accessed immediately in state eDBPROJECT_CONFIGURATION or after the instancing of the RunTime Project

If there are optional elements not filled in ODX no exception shall be used

Within the database part templates for all DiagComPrimitives and their parameters, information for ECU (re)programming and the information concerning the ECUs and the Vehicle Connector Table are deposited

The interfaces derived from MCDDbDiagComPrimitive can poll the meta information of various communication primitives During execution, objects populated with data from the ODX serve as templates for the runtime communication primitives.

7.7.2.3 Structure of the runtime side

The communication actions during runtime are executed through DiagComPrimitives, which encompass Services and three job types: FlashJob, SingleEcuJob, and MultipleEcuJob A notable aspect of the Diagnostic component is the utilization of RequestParameters as inputs for the DiagComPrimitives.

ResultState as Snapshot for the state of the Result

MCDDiagComPrimitive is the superior class for all runtime communication primitives Communication

Primitives represent, for example, state transitions of the Logical Link (MCDStartCommunication) and real communication objects such as, for example, Services and Jobs Jobs and Services are derived from

DataPrimitives and thus they have to be handled alike

The parent functionality in objects MCDError, MCDResponseParameter,

The MCDResponseParameters, MCDResponse, MCDResponses, and MCDDiagComPrimitive components of the model enable users to navigate in both top-down and bottom-up directions The functionality is always associated with the logical parent of the object.

DiagComPrimitive, the parent is the LogicalLink

Table 5 defines the delivered parent

Table 5 — Get parent functionality in diagnostic Class delivers

MCDError MCDResponseParameter or MCDResponse or MCDResult

Within the Entity Relationship diagrams (ERD) the relations between the single interfaces or the objects to be created from these are visualized

7.7.4.2 Relation between Vehicle Connector Information Table and Logical Link Table

Figure 15 shows the DbProject and relation to Logical Link and Vehicle Information Table

Vehicle Connector Information Table Logical Link Table

Figure 15 — DbProject and relation to Logical Link and Vehicle Information Table

This ERD illustrates the relationships between the project's database interface and the ECUs, as well as the vehicle information included in the project It specifies the types of information that can be organized into collections and indicates the required quantity of respective objects within the database.

In the Logical Link Table each ECU will occur in several Locations if there are different paths to this ECU

Each Logical Link is associated with a single Location and a Physical Vehicle Link, as indicated in the Logical Link Table The Vehicle Connectors and their corresponding ConnectorPins are derived from the Physical Vehicle Link The Vehicle Information Table details the Vehicle Connectors along with their pin assignments and the related Logical Links The Logical Link specifically references the Physical Vehicle Link, which outlines the connections between pins and the ECU.

Besides the VehicleInformationTables that are defined in ODX, an MCD System may optionally support the concept of runtime generated Vehicle Information Tables

Collections

A Collection consists of individual elements, with no specific ordering criteria defined by the MVCI diagnostic server specification Elements can be accessed using an Index, which also allows for iteration over the Collection, starting the count at zero The Collection provides a way to query the current number of elements it contains The NamedCollection interface, derived from the general Collection, enables users to retrieve a list of element names and access elements by their names The type of elements stored in a Collection is determined by the InterfaceName, while the methods getItemByIndex and getItemByName are declared within specific Interfaces, ensuring type safety.

Figure 26 shows the principle of collections

getItemByIndex(index : A_UINT32) : MCDDbLogicalLink

getItemByName(name : MCDDatatypeShortName) : MCDDbLogicalLink

getItemByIndex(index : A_UINT32) : MCDResult

Figure 27 shows the RunTime collections MCD

Within this ERD the associations between MCDProject and its Logical Links are shown Also the relations of the Logical Link to the DiagComPrimitives and Services are visible

Logical Links and DiagComPrimitives (incl Services and Jobs) do not form a Collection that can be polled via the API

Runtime collections are exclusively mapped to Results and their sub-structures, ensuring that names are never duplicated since they are generated by the server or Job.

Collections serve to list database objects that share a common interface, reflecting the static content of the project's database, where no additions or modifications are permitted Always derived from MCDNamedCollection, these collections allow access to their items both by index and by name, ensuring the uniqueness of item names within the database.

Figure 28 shows the database collections part I

Figure 29 shows the database collections part II

Figure 29 — Database collections part II

Registering/deregistering of the EventHandler

For each Interface that may use an EventHandler, two methods have to be implemented:

Registering: setEventHandler (handler.MCDEventHandler): A_UINT32,

Deregistering: releaseEventHandler (Id: A_UINT32): void

Multiple EventHandlers can be simultaneously connected to an object, each identified by a unique ID assigned during registration.

If the server cannot register another EventHandler because of internal restrictions, e.g resources or exceeding MAX A_UINT32 (2 32 ) EventHandlers, an MCDProgramViolationException will be thrown

It contains the error eSYSTEM_RESOURCE_OVERLOAD

To ensure that EventHandling operates effectively with a single EventHandler, all event reception methods must be included within each EventHandler The Client-Implementation determines the number of registered EventHandlers and whether they implement all event handling methods or use some merely as basic data sinks Each registered EventHandler must provide all necessary methods, while the specific functionality derived from these methods is dependent on the implementation.

The EventHandler can be registered with key runtime objects such as MCDSystem and MCDLogicalLink When an event is triggered for the Logical Link, it is directed solely to the EventHandler registered with that link If no EventHandler is associated with the Logical Link, the event is then sent to the EventHandler of the MCDSystem Importantly, an event is not dispatched to both EventHandlers if they are registered with both objects.

To ensure proper event handling, at least one event handler must be registered with the MCDSystem, as any unhandled events will ultimately be directed to it.

Registering an EventHandler in the MCDSystem is optional; it can receive all messages as the sole EventHandler if no other handlers are registered.

Figure 30 shows the using of EventHandler registered on registered on

The releaseEventHandler method can be invoked in any state without causing exceptions It is important for client programmers to call the releaseEventHandler in the same states where the corresponding setEventHandler was previously called.

Tiêu đề	Road Vehicles — Modular Vehicle Communication Interface (MVCI) — Part 3: Diagnostic Server Application Programming Interface (D-Server API)
Trường học	University of Alberta
Thể loại	Tiêu chuẩn
Năm xuất bản	2012
Thành phố	Switzerland

Định dạng
Số trang	288
Dung lượng	2,41 MB