OTX Basic concepts Open Diagnostic Framework Demonstration

Transcription

1

2 2

3 Diagnostic Process Chain Past 3 System supplier Development Production Diagnostic system supplier Service The conventional diagnostic process is characterized by an heterogeneous exchange of diagnostic information.

4 Diangostic Process Chain Future: OTX/ODX 4 System supplier Development Production Diagnostic system supplier Service Supplier Diagnostic Database Manufacturer Diagnostic Database Manufacturer Diagnostic Database Internet OTX ODX OTX ODX OTX ODX OTX ODX Exchange of standardized diagnostic data throughout all stages of the vehicle life cycle basic principle: Single Source

5 ODX, MCD 2 (ISO ) OTX Open Diagnostic Test sequence exchange 5 OTX = Open Test sequence exchange (ISO 13209) Domain specific language on high abstraction level Goal: Formal, graphical description of diagnostic sequences Platform and tester independent exchange format Includes powerful concepts to reduce complexity Process safe alternative for Java-Jobs in ODX Application area: Vehilce diagnostics, Test automation, HIL-Simulation etc. Initial application: exchange format for ODX based diagnostic sequences Only through OTX/ODX there is a complete, data-driven solution for the complete process chain Test and Diagnostic applications Test and OTX Diagnostic (ISO 13209) applications API D-Server API, MCD 3 (ISO ) Modular VCI Runtime System (MVCI, ISO 22900) D-PDU API, MCD 1 (ISO ) Vehicle Communication Interface VCI ECU ECU ECU OTX ODX

6 Diagnostic Sequnces in interaction with user and vehicle 6 Off-Board Kommunikation A Request/Response x? ECUs y? z? B C C D GUI ShowScreen E E Recursive function call Test sequence OTX External sensors & actors Diagnostic tester in development, production & service

7 Application in the Diagnostic Process 7 OTX ECU manufacturer Development of diagnostic functions HIL-Tests Diagnostics in production After-Sales Diagnostics Diagnostic Docu (GVO, Euro 5, Hotline ) Development Production Service Goal: Exchanging and archiving verified tested diagnostic sequences

8 Interfaces & Extenstions 8 Diagnostic Tester Application DateTime Logging EventHandling I18n StringUtil Math Quantities OTX OTX Core Processing System HMI DiagCom Job/Flash Measure HMI Device (e.g. Keyboard, Mouse, Screen ) Diagnostic Runtime System (e.g. MVCI Server, D-Server, ) Measurement Data Acquisition Other Device (e.g. HIL-API, ASAM GDI)

9 Simple OTX Sequence 9 <otx name="odfproject1" package="package1" version="0.9.4" timestamp=" t09:34:08"> <validities> <validity name="validity1"> <realisation xsi:type="booleanliteral" value="true" /> </validity> </validities> <procedures> <procedure name="workflow1"> <realisation> <declarations> <variable name="variable1"> <realisation> <datatype xsi:type="integer" /> </realisation> </variable> </declarations> <flow> <action name="setcontextdataactivity1" id="setcontextdataactivity1"> <specification>umgebungsvariable setzen...</specification> <realisation xsi:type="env:setcontextdata"> <env:identifier xsi:type="stringliteral" value="data1" /> <env:term xsi:type="stringliteral" value="abc" /> </realisation> </action> </flow> </realisation> </procedure> </procedures> </otx>

10 OTX Timeline Dec New Work Item Proposal submission to ISO 25 Feb DIS-Ballot (Draft International Standard) 28 June 2011 DIS-Release (Draft International Standard) Core only Core only 09 Dec Feb May June 2011 Begin of development of the ODF Release ODF Version 2.0 Distributable Beta version of ODF Version 3.0 (planned) Release ODF Version 3.0 (planned) Mile stone Today

11 Advantanges & Benefits 11 Reusability (single source) Increase of security through less process steps Simple and quick verification Improvement of maintainance XML format: Maschine and human readability Manufacturer independence Automated tools for configuration, documentation, code generation etc. Generic creation of diagnostic applications Goal: Exchanging and archiving verified tested diagnostic sequences

12 12

13 Basic Concepts 13 Basic concepts representing the experiences in the creation of diagnostic seuqunces. Goal: Reducing and controlling complexity Specification/realisation concept Process management Context concept Validity concept Variant management Signature concept

14 Specification/Realisation Concept I 14 OTX supports a 3 step development process: 1. Specification stage To specify sequences in an early stage of the developement process The general sequence logics is known Details for an executable sequence are still unknown but can be specified in prose 2. Intermediate stage A mix of specification and realisation The sequence creation implements the realisation based on the specifcation The sequence is executable already! Missing realisations are simulated through appropriate dialogs 3. Realisation stage For each specification a realisation has been implemented The sequence is fully executable Important: In each of the 3 stages the sequence can be validated, saved, and exchanged!

15 Specification/Realisation Concept II 15 Specification Stage Intermediate Stage Realisation

16 Context Concept I 16 Mapping mechanism inside the runtime system for environment parameters : Vehicle data (e.g. model, sales person, identification number, motorization etc.) Diagnostic application data (e.g. name, version, used VCI etc.) User data (e.g. user name, user rights, idle time etc.) Environment data (e.g. location, version of operating system etc.) Realisation via global context variables Every context variable is bound to an identification routine at runtime in order to retrieve the value of the variable Identification routines may either be proprietary or OTX procedures Advantages: Working as if using global constants Reusabilty of the existing structure with optimal migration via stepwise mapping to OTX procedures When switching to other runtime environments only the mapping layer has to be adapted Context variables can easily be simulated externally

17 Mapping (OTX-Runtime) Context Concept II 17 OTX Sequence Diagnostic Application VIN Typ: String, Default: MODEL Typ: String, Default: GetVIN(); GetModelNumber(); STEERING Typ: String, Default: left MANUFACTORING Typ: Boolean, Default: False SERVICE Typ: Boolean, Default: True GetSteeringType(); n.a. n.a. DEBUG_MODE Typ: Boolean, Default: False Context variables used as global constants n.a. Internal Routines of the diagnostic application

18 Validity Concept 18 Based on the context concept In order to customize the sequences to different environment conditions at runtime So-called validities are definied globally. A validity is either a boolean context variable, or a composed logical expression, e.g. several context variables. Nodes can be bound via the ValidFor attribute to a validity which will only be executed if the validity returns TRUE An action node may contain several realisations Thus context dependent sequence parts may be activated or deactivated Advantages Clear borderline between static and dynamic decisions Reduction of the number of branches due to implicit control via environment data and not explicitly via branches Compact readable sequences that improve the understanding of the test logic Avoidance of redundancies due to storing of frequently used validities at a central location Presentation of different environment scenarios via on and off switch of validities (filtering)

19 Validity Concept 19 Using branches Using validities

20 Signature Concept 20 Similar to validity concept, but on procedure level A signature describes an interface to a procedure (prototype) A signature equals a procedure without realization A signature contains a name, a specification and a set of input and output parameters Procedures may be called indirectly via signatures The caller only has to know the parameters and the specification of the procedure but not the implementation details Signatures allow the creation of generic sequences that can adapt to different environment conditions at runtime Advantages: Sequences don t have to be changed if a new context is added Increases the maintenance for long term availability of test sequences Makes it possible to develop distributed test sequences. The signature itself represents the formal definition of the interfaces among the individual partners Avoidance of redundancies via storing of frequently used signatures at a central location

21 Signature Concept 21 Using validities Using signatures ValidFor: isvintagemodel ValidFor: ismodernmodel The runtime system calles one of the two procedures based on the validity

22 Comparing the Concepts 22 Using branches Using validities Using signatures Normaler Ablauf 11 activities 13 activities 22 activities Advantages: Avoidance of branches Reduces the presentation to the actual test logic (11 activities) Better maintainance and long term availability Avoiding redundancies Possibility for distributed development of test sequences

23 23

24 Open Diagnostic Workflow Overview 24 Diagnostic database Standardized exchange format for diagnostic data ODX ISO Diagnostic sequences Standardized exchange format for diagnostic sequences OTX ISO Diagnostic runtime system Standardized programming interface for ECU communication MVCI-Server ISO 22900

25 Highlights Basic concepts Open Diagnostic Framework Demonstration Data-driven solution for the complete diagnostic process chain Simple custom extensibility at almost each layer Concepts for complexity reduction User group adaption Open Diagnostic Workflow Flexible usage: Stand-alone or SDK On-the-fly code generation (C#, no execution interpreter!) 25 Specification, realisation, validation, documentation & test of OTX sequences Independant of diagnostic runtime system Completely new development Connection and generation GUI/HMI Fast processing of very large OTX databases Native and direct working on OTX data (no im-/export!) OTX

26 Open Diagnostic Workflow Main Characteristics 26 Main tasks: Specification Realisation Documentation Test and Execution of OTX sequences Design characteristics: Openness Adaptable Extensibility Target groups: Development Production Service

27 Open Diagnostic Workflow Principle Architecture 27 ODF - Open Diagnostic Framework Database-Modul OTX-Designer Forms-Designer Test-Environment OTX OTX-API Project-Explorer Control-Library Debugger XML-DB Activity-Library Data-Binding Unit-Tests OTX Runtime Environment ODX MVCI-Server + PDU-Simulation Standardized Diagnostic RT-Systems SDX * D-PDU API Legacy RT-Systems Simulation Proprietary Diagnostic RT-Systems VCI - Vehicle Communication Interface ECU s * SDX = Simple Diagnostic Data Exchange Format by emotive to support proprietary Diagnostic Runtime Systems

28 Open Diagnostic Workflow Runtime Environment 28 OTX execution system Data processing OTX XML-DB XQuery OTX-API ODF- Runtime C# Compiler DLL OTX- Runtime Database module ODF runtime Storage requirement on hard-drive ca. 20 MB ca. 3 MB Data processing as OTX format Data processing in binary format

29 Open Diagnostic Workflow Features 29 OTX-Designer Graphical specification and implementation of diagnostic sequences Direct, native working on OTX Validation of sequences at design time Execution, test and debugging of sequnces at design time Monitoring of diagnostic communication and variable changes Configurable designer modes All, Compact, Minimal, etc. OTX-API Fast access to very large OTX databases OTX-Runtime On-the-fly C# code generation of high performance Independent of diagnostic runtime system Support of different standardized and proprietary diagnostic runtime system: DSA Prodis.MCD (ODX 2.0.1, 2.0.2, 2.1.0, 2.2.0) samtec samdiax Further systems, e.g. CBF runtime quickly integrated High-performance, optimized handling of resources, multi-channeling, multi-instance handling PDU simulation for development of sequences without communication with ECU Screen Designer Easy graphical creation of modern GUIs Simple binding of diagnostic sequences variables to GUI controls for in and output Language manager to localize the application Simple distribution of the created application to third parties via MSI or MSM General: Object search Forward-driven data input Undo/Redo, Drag&Drop References adjustment Version management User profiles IDE in German and English

30 Open Diagnostic Workflow Standards, Hardware & System Requirements 30 Supported diagnostic standards: MVCI Server API (ISO , ASAM MCD-3D Server) ODX (ISO , ASAM MCD-2D) OTX Beta Version (ISO 13209) D-PDU-API (ISO ) CAN (ISO 11898) K-Line (ISO 9141) UDS (ISO 14229) ISOTP (KWP 2000 on CAN, ISO/DIS ) KWP 2000 (ISO 14230) Supported hardware (Vehicle Communication Interface): Bosch MDI DSA MDI-G samtec HSX, HS+, HSlight Vector CANCardXL, CANCaseXL, CANBoardXL Further interfaces with standardized D-PDU-API interface System requirements PC with Windows XP SP2 32-Bit or higher.net Framework 3.5

31 31

32 Open Diagnostic Workflow Stand-Alone Application 32

33 Open Diagnostic Workflow ACTIVITY LIBRARIES PROJECT EXPLORER Visual Studio Plug-In I 33 OTX-DESIGNER VARIABLES VALIDATION PROPERTIES TRACE WINDOW DIAGNOSTIC COMMUNICATION TRACE WINDOW VARIABLES

34 Open Diagnostic Workflow Visual Studio Plug-In II 34 DEBUGGING

35 Thank You for Your Attention! 35 Contact us! We can help out. Further comprehensive information on OTX and vehicle diagnostics can be found on our website at