DOCSLIB.ORG

Quo Vadis SAE J1939 Standardization

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Quo Vadis SAE J1939 Standardization Quo vadis SAE J1939 standardization Peter Fellmeth, Holger Söhnle (Vector Informatik) Standardization has forced commercial ve- hicle developers to work at the limits of performance [2]. From a communication perspective, development of the 500-kbit/s data trans- port layer is a long overdue step. European commercial vehicle producers in partic- ular are seeking a final de- cision in the near future. The specification will be re- leased in a separate docu- ment, J1939-14, and its key aspects are: ue to new application erates by the plug-and-play chased either individually X Twice the bit-rate, Dlayer requirements, principle. The J1939 stan- or together as a package in 500 kbit/s instead of SAE is continuing to de- dard is an active standard so-called “JPaks” from the 250 kbit/s velop the J1939 standard, that currently consists of SAE website [1]. X Use of shielded and un- which is primarily used 19 documents. The respon- shielded cable as de- to network powertrains in sible SAE subcommittees fined in [2] and [3] is still commercial vehicles. How- generally meet four times a More bandwidth possible ever, optimizations and ex- year to decide on changes X Topology is essentially a tensions are being made and further developments. For years now, the maxi- bus that has branch lines in the other communication The current versions of the mum 250-kbit/s bandwidth with a max. length of 1 m. layers as well, right up to the documents may be pur- specified in the standard To connect diagnostic physical transmission layer. This article summarizes the current state of discussions within the SAE J1939 work- ing committee, such as the planned introduction of the 500-kbit/s physical trans- mission layer and chang- es to network management. Moreover, it also explains ongoing efforts to standard- ize J1939 in Autosar Re- lease 4 and WWH-OBD (world-wide harmonized on- board diagnostics) diagnos- tics. Based on the CAN bus (high-speed CAN per ISO 11898), the SAE J1939 standard is used primarily to network the powertrain and chassis in commercial vehicles. The protocol cre- ates a uniform foundation for communication between the electronic ECUs (elec- tronic control unit) and op- Status of SAE J1939 documents (September 2010) 62 CAN Newsletter 1/2011 Microcontrollers Digital Signal Analog Memory RF & Wireless Controllers tools, a branch line (from of sensors with a direct bus the diagnostic socket connection. The number of to the diagnostic tool) new devices is growing rap- with a length of 5 m may idly due to heightened ex- sometimes be used. haust emissions require- X The bus is terminated at ments and the addition of both ends with a char- assistance systems. Many acteristic impedance of alternatives were proposed 120 . Up to 30 nodes but then rejected. They are possible. ranged from a dedicated network for sensors to im- Standardization The specification for the di- plementation of a new pro- agnostic plug [4] was adapt- tocol – e.g. by using previ- ed to 500-kbit/s operation. ously reserved data pages. In addition, a new “Type II” Meanwhile, the fact diagnostic socket is being was that SAE has not as- used in the vehicle, which signed any more new ad- has a green color-coding, dresses. That was an un- and its connector keying satisfactory situation for prevents use of the previous ECU suppliers. Often, they 250-kbit/s “Type I” diagnos- did not know whether their tic plug. A “Type II” plug is product designs would have compatible with a “Type I” lasting value. In the latest Fig. 2: Layout of a 29-bit CAN-ID in J1939 networks socket. Another change is version of Network Manage- that the “Type II” diagnos- ment, SAE recommends im- specific components of the These changes in tic socket defines pins pre- plementing “Address Arbi- 64-bit device name. This Network Management are viously used for SAE J1708/ trary Capable” ECUs. These might be necessary if the supported in version 7.5 J1587 as reserved. Conse- ECUs are able to compute relevant function or mea- of Vector’s CANalyzer. quently, a J1708-/J1587-net- their own addresses based surement parameter is de- J1939 analysis tool and its work can no longer be ad- on the momentary vehicle rived from the device name. CA Noe. J1939 test tool. dressed via a “Type II” diag- configuration – and indeed So, the device name can be nostic plug. at runtime. Essentially, this used to identify the position Autosar and J1939 approach aims to utilize the of an exhaust gas tempera- come closer together SAE gets serious mechanism of dynamic ad- ture sensor – upstream or about dynamics dress allocation that has downstream of the catalytic The introduction of Auto- always existed in the com- converter, on the right or left sar in the passenger car in- Changes are also being mercial vehicle field, but side of a dual-flow exhaust dustry is ramping up quick- made in the area of Network has never really been im- system. Changes can be ly. Yet, there is also interest Management [5]. For a long plemented or used before. made to multiple ECUs in in exploiting the benefits of time now, the J1939-com- In conjunction with Net- sequence and activated at Autosar in commercial ve- mittee has been deliberat- work Management, the new- a specific point in time. This hicle and the agricultural ing over ways to handle the ly added Name Manage- could be helpful, for exam- machine markets. Howev- short supply of permanent- ment should be mentioned ple, in a case where multi- er, the special requirements ly assigned ECU address- for the sake of complete- ple ECUs of a network need of these markets have not es. This is especially prob- ness. This is a standard- to be assigned a new func- been a focus in the devel- lematic for manufacturers ized interface for changing tion simultaneously. opment of Autosar. There- fore, the Autosar versions released so far have very limited potential in these markets. In particular, the requirements of SAE J1939 cannot be mapped to the current Autosar concept, or only in a very limited way. The “static” approach of Autosar stands in con- trast to the “dynamic” be- havior of J1939. The Auto- sar architecture only allows fixed CAN-IDs (identifiers), i.e. there is a fixed alloca- tion between precisely one CAN-ID and one message layout. In contrast to this, a J1939-specific message Fig. 3: Autosar basic software from Vector contains the two J1939 transport protocols layout is only allocated to a BAM and CMDT specific part of the CAN-ID, 64 CAN Newsletter 1/2011 ,).58DEVICEDRIVER You CAN get it AVAILABLE Hardware & software for CAN bus applications… 3&$15RXWHU3URXWHU3UR 3&$186%3UR #ONÚGURABLEFOURCHANNELLEFOURCHANNEL (IGH SPEED53" #!.ROUTERWITHDATAWITHDATA INTERFACEWITHGALVANICWITHGALVANIC LOGGERINCLCONÚGURATION ISOLATIONFORCONNECTINGUPFORCONNECTINGUP SOFTWARE TO#!.AND,).BUSSESAND,).BUSSES 3&$1'LDJ3& 0#!. $IAGISAHANDHELD#!.BUSDIAGNOSTICSUNIT4HENEW0# MODELOFFERSENHANCEDFUNCTIONALITYMO #LEAR#!.TRAFÚCREPRESENTATIONINLISTS CONÚGURABLE SYMBOLICREPRESENTATIONOFRECEIVEDMESSAGES 4RANSMISSIONOFINDIVIDUAL#!.FRAMESOR#!.FRAMELISTS "UILT IN CHANNELOSCILLOSCOPEFORDETAILEDANALYSISOF THEDIFFERENTIAL#!.SIGNALORANOPTIONALEXTERNALSIGNAL 3&$13&,([SUHVV 3&$1*356/LQN TRIGGERINGBY#!.)$SOROTHEREVENTS "ITRATEDETECTION BUSLOADANDTERMINATIONMEASUREMENT #!.INTERFACEFOR0#) $EVELOPMENTPLATFORM 7INDOWSSOFTWAREFOREASYDEVICECONÚGURATIONAND %XPRESSSYSTEMS!VAILABLE WITH#!. '03 AND'023 TRANSMITLISTDEÚNITION UPLOADVIA53"CONNECTION AS CHANNEL CHANNEL )NTERPRETATIONOF/"$ 3TORAGEOFDIAGNOSTICRESULTS#36 "-0 ONANINTERNAL ANDOPTO ISOLATEDVERSION &-3 $4#/ #I! '"MASSSTORAGE53"DEVICE 3&$1([SUHVV&DUG 3&$13&,([SUHVV #!.INTERFACEFOR%XPRESS #!.INTERFACEFOR0#) #ARDSLOTS!VAILABLEAS %XPRESSSLOTS!VAILABLE CHANNEL CHANNEL AND AS CHANNEL CHANNEL OPTO ISOLATEDVERSION ANDOPTO ISOLATEDVERSION 3&$1([SORUHU 4HEUNIVERSALTOOLFORDEVELOPINGANDMONITORING#!. NETWORKS %XTENSIVEUSERINTERFACEIMPROVEMENTS&ILEMANAGE MENTVIAPROJECTS CONÚGURATIONOFALLELEMENTSWITHTHE PROPERTYEDITOR ANDWINDOWARRANGEMENTUSINGTABS 3IMULTANEOUSCONNECTIONSWITHMULTIPLENETWORKS#!. INTERFACESOFTHESAMEHARDWARETYPE #ONÚGURABLESYMBOLICMESSAGEREPRESENTATION 3&$1F3&, 7DNHDORRNDW $ATALOGGINGWITHTRACERSANDTHE CHANNEL,INE7RITER RXUZHEVLWHIRU 6"3CRIPTINTERFACEFORTHECREATIONOFMACROS #!.INTERFACEFORC0#) SLOTS!VAILABLEAS WKHLQWHUQDWLRQDO &UNCTIONALITYUPGRADESWITHADD INSEG-!DD IN VDOHVSDUWQHUV 5SERINTERFACELANGUAGEIN%NGLISHOR'ERMAN CHANNELAND CHANNEL OPTO ISOLATEDVERSIONS www.peak-system.com /TTO 2OEHM 3TRq$ARMSTADT'ERMANY 0HONE q&AX q% MAILINFO PEAK SYSTEMCOM known as the parameter the United Nations and doc- group (PG). Some of the umented in its Global Tech- other components of the nical Regulation 5 (GTR 5). 29-bit CAN-ID are dynamic ISO 27145 represents the and not defined at the time technical implementation of of configuration. Such a dy- GTR 5. It establishes tech- namic CAN-ID can be mod- nical constraints for WWH- eled in Autosar by creating OBD. WWH-OBD initially a separate static CAN-ID for targets the commercial ve- each combination of priori- hicle market, but eventual- ty, source address (SA) and ly it should be extended to Standardization destination address (DA) other vehicle industries as that can occur in a network. Fig. 4: The WWH-OBD is specified in ISO 27145 well. When all nodes of a ISO 27145 consists of J1939 network are known, More in-depth support OEMs Vector actively par- six parts. The current doc- and node addresses are al- of J1939 requirements is ticipates in efforts to spec- ument status is a Draft In- ready defined at the time of planned for the end of 2012 ify these J1939
Load more

Recommended publications
  • Vector Informatik Gmbh
    THE HANSEN REPORT ON AUTOMOTIVE ELECTRONICS. A Business and Technology Newsletter VOL. 18, NO. 6◆◆ PORTSMOUTH, NH USA JULY/AUGUST 2005 Software Process BMW Leads in Chassis Control Standards Gaining FlexRay Network Is Key Enabler from steering angle, acceleration and ride height sensors. Influence FlexRay is not just for steer- or brake- “This is a pilot project for us to learn by-wire anymore. BMW is about to bring what it means to bring FlexRay into a se- As software becomes more and more to market some groundbreaking new chas- ries car,” noted Karl-Heinz Gaubatz, gen- essential to the delivery of vehicle fea- sis control features implemented on a eral manager of electronics driving tures, carmakers and suppliers, particularly FlexRay network—a world’s first. This dynamics and lateral dynamics for BMW. in the West, are taking steps to ensure unexpected deployment of FlexRay comes BMW will build 15,000 cars per year with that their software development processes well before by-wire brakes or steering will this FlexRay application so the carmaker yield high-quality, reliable products. Two be ready for production vehicles. and its suppliers can gain experience with approaches have emerged: CMMI (Capa- By-wire systems operate without me- the network hardware and software before bility Maturity Model Integration) and chanical or hydraulic linkages so they it goes into high volume production. ISO/IEC (International Standards Orga- need safety-critical components such as “In the future, all new cars from BMW nization/International Electro-technical FlexRay to ensure reliability. FlexRay is a that come into production after 2006 will Commission) 15504, a.k.a.
    [Show full text]
  • Cyber Security Mechanisms for Connected Vehicles
    Infineon Security Partner Network Partner Use Case Cyber Security Mechanisms for Connected Vehicles Protecting automotive vehicle networks and business models from cyber security attacks Products AURIX™ www.infineon.com/ispn Partner Use Case Use case Application context and security requirement The rapidly growing connectivity of vehicles is opening numerous opportunities for new features and attractive business models. At the same time, the potential for cyber-attacks on vehicle networks is also growing. Such attacks threaten the functional safety of the vehicle and could cause financial damage. Challenge Vehicles consist of numerous interconnected electronic control units (ECUs) with numerous internal and external interfaces. The overall system only works if the software executed on the ECUs and the data transmitted between ECUs is protected against manipulation. Implementation The solution requires multiple layers of security mechanisms. The foundation is provided by microcontrollers which are equipped with security cores e.g. Aurix Hardware Security Module (HSM). They provide hardware acceleration for cryptographic primitives such as Advanced Encryption Standard (AES) and Elliptic Curve Cryptography (ECC) as well as protected storage of cryptographic keys. Based on these capabilities Vector is providing software and drivers for these HSMs that enable higher level security mechanisms such as secured boot, secured communication or secured diagnostic access. User benefits: Vehicle Electrical/Electronic (EE) architectures which integrate
    [Show full text]
  • Grafikbasierte Analyse Und Bewertung Heterogener Automobiler Netzwerke
    Masterthesis Jonathan Wendeborn Entwurf und Vergleich zweier Verfahren zur Analyse und Bewertung heterogener automobiler Netzwerke Fakultät Technik und Informatik Faculty of Engineering and Computer Science Department Informations- und Department of Information and Elektrotechnik Electrical Engineering Jonathan Wendeborn Entwurf und Vergleich zweier Verfahren zur Analyse und Bewertung heterogener automobiler Netzwerke Masterthesis eingereicht im Rahmen der Masterprüfung im Masterstudiengang Informations- und Kommunikationstechnik am Department Informations- und Elektrotechnik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg in Zusammenarbeit mit: Vector Informatik GmbH Borsteler Bogen 27d 22453 Hamburg Betreuender Prüfer: Prof. Dr.-Ing. Aining Li Zweitgutachter: Prof. Dr. Franz Korf Industrieller Betreuer: Dipl.-Ing. Jörn Haase Abgegeben am 25. August 2016 Jonathan Wendeborn Thema der Masterthesis Entwurf und Vergleich zweier Verfahren zur Analyse und Bewertung heterogener automobiler Netzwerke Stichworte System-Level-Simulation, Analyse, Bewertung, heterogene Netzwerke, Echtzeit-Ethernet, Time-Triggered-Ethernet, AVB, TSN, CAN, Gateway, OMNeT++, CANoe, Elektrik-/Elektronik-Architektur, Metrik, Latenz, Jitter, Datenübertragungsrate, Paketverlustrate, Puffer, Binlog, BLF, COM, .NET, CAPL Kurzzusammenfassung Durch die Einführung von Echtzeitfähigkeit bei Ethernet können neuartige Netzwerke entwickelt werden, welche neue Funktionen ermöglichen und Kosten sparen. Um die Tauglichkeit eines Netzwerks
    [Show full text]
  • Proof Your Canopen Products – Conformance and Interoperability
    December 2012 B 25361 CAN Newsletter Hardware + Software + Tools + Engineering Proof your CANopen products – conformance and interoperability Testing Easy access to CAN network analysis Isobus testing with implement and remaining bus simulation www.can-newsletter.org Solutions for open networks from one source Open CAN-based protocols are the basis of networking in com- mercial vehicles, avionics and industrial control technology. Vector supports you in all development phases of these systems: > Systematic network design with CANoe, ProCANopen and CANeds > Successful implementation with source code for CANopen, J1939 and more > Efficient configuration, test and extensive analysis with ProCANopen, CANoe and CANalyzer Multifaceted trainings and individual consulting complete our extensive offerings. Thanks to the close interlocking of the Vector tools and the competent support, you will increase the efficiency of your entire development process from design to testing. Further information, application notes and demos: www.vector.com/opennetworks AFDX® is an Airbus‘ registered trademark Vector Informatik GmbH Proof your CANopen products – conformance and interoperability Holger Zeltwanger Author Holger Zeltwanger CAN in Automation e. V. Managing Director [email protected] Definitions Compatibility: Capability to exist or perform in harmonious, agreeable, or congenial combination with others. Conformance: Compliance in actions, behavior, etc., with certain accepted stan- dards or specifications. Compliancy: A disposition or tendency to yield to the will of Figure 1: Current CANopen Conformance Test (CCT) tool others. he bell rings. The ap- CAN bit-rates of the tool and nor corrections of the EDS, Ilnteroperability: Tprentice opens the door the devices to 250 kbit/s, he links it to the test tool The ability of systems or of the CiA office.
    [Show full text]
  • Hardware + Software + Tools + Engineering Retrofitting Port Cranes Set to Boom CAN in Aquaplaning Warning
    June 2018 CAN Newsletter Hardware + Software + Tools + Engineering Retrofitting port cranes set to boom CAN in aquaplaning warning system Applications Online diameter control during wire and cable production www.can-newsletter.org New CAN FD Interfaces PCAN-M.2 PCAN-PCI/104-Express FD CAN FD Interface for M.2 (PCIe) CAN FD Interface for PCI/104-Express CAN interface for the M.2 slot (uses PCIe lane) 0#) %XPRESSCARD LANEX 1, 2, or 4 High-speed CAN channels (ISO 11898-2) Form factor PC/104 Form factor M.2 type: 2280/2260-B-M; Height: Single and Up to four cards can be used in one system Dual Channel 4.6 mm; Four Channel 10.2 mm 1, 2, or 4 High-speed CAN channels (ISO 11898-2) #OMPLIESWITH#!.SPECIÚCATIONS!"AND&$ #OMPLIESWITH#!.SPECIÚCATIONS!"AND&$ CAN FD support for ISO and Non-ISO standards switchable CAN FD support for ISO and Non-ISO standards switchable #!.&$BITRATESFORTHEDATAÚELDBYTESMAX FROM #!.&$BITRATESFORTHEDATAÚELDBYTESMAX FROM 20 kbit/s up to 12 Mbit/s 20 kbit/s up to 12 Mbit/s CAN bit rates from 20 kbit/s up to 1 Mbit/s CAN bit rates from 20 kbit/s up to 1 Mbit/s CAN bus connection via connection cable and D-Sub, Connection to CAN bus through D-Sub slot bracket, 9-pin (in accordance with CiA® 303-1) 9-pin (in accordance with CiA® 303-1) MCP2558FD CAN transceiver MCP2558FD CAN transceiver Galvanic isolation on the CAN connection up to 300 V, Galvanic isolation on the CAN connection up to 500 V, separate for each CAN channel separate for each CAN channel CAN termination can be activated through a solder jumper, CAN termination
    [Show full text]
  • CAN.LIN.MOST.Flexray Manual
    CANoe DENoe .CAN.LIN.MOST.FlexRay Manual Version 4.1 Vector Informatik GmbH, Ingersheimer Str. 24, D-70499 Stuttgart Tel. +49 711 80670-0, Fax +49 711 80670 111 Email [email protected], Internet http://www.vector-informatik.de III Subsidiaries France Sweden Vector France SAS VecScan AB 168, Boulevard Camélinat Fabriksgatan 7 F-92240 Malakoff S-41250 Göteborg Tel.: +33 1 4231 4000 Tel.: +46 031 79901 35 Fax: +33 1 4231 4009 Fax: +46 031 79903 05 http://www.vector-france.com http://www.vecscan.com/ Japan USA Vector Japan Co., Ltd. Vector CANtech, Inc. Nishikawa Bldg. 2F Suite 550 3-3-9 Nihonbashi, Chuo-ku 39500 Orchard Hill Place J-103-0027 Tokyo USA-Novi, Mi 48375 Tel.: +81 3 3516 7850 Tel.: +1 248 449 9290 Fax: +81 3 3516 7855 Fax: +1 248 449 9704 http://www.vector-japan.co.jp http://www.vector-cantech.com For Distributor Addresses please have a look on our website: www.vector-informatik.com © Vector Informatik GmbH CANoe/DENoe Manual Version 4.1.1 IV International Quality Standard Certificate The Quality Management of Vector Informatik GmbH is being certified throughout since 1998-08-19: • 2001-11-27 according to DIN EN ISO 9001:2000-12 Certificate number: 70 100 1498 • 1998-08-19 according to DIN EN ISO 9001:1994-08 Certificate number: 70 100 F 1498 TMS Typographic Conventions Identifies important notes Note: • Identifies enumerations (bullet items) Î '1.0 Introduction' Identifies references to further chapters of this manual [OK] Notation for buttons in dialogs <TAB> Notation for keys on the computer keyboard <Strg>+<Z> Notation for keys of the computer keyboard which should be pressed simultaneously Add… Notation for menu, command and dialog names File│File open… on message 0x100 Notation for MS-DOS syntax or program code © Vector Informatik GmbH CANoe/DENoe Manual Version 4.1.1 V Notes on the new naming convention CANoe CANalyzer DENoe DENalyzer The multi-bus functionality and die modular configuration concept of the program variants require a new naming convention of several Vector products.
    [Show full text]
  • Canoe/Canalyzer Option .Scope
    CANoe/CANalyzer Option .Scope User Manual Version 2.12 English Imprint Vector Informatik GmbH Ingersheimer Straße 24 D-70499 Stuttgart Vector reserves the right to modify any information and/or data in this user documentation without notice. This documentation nor any of its parts may be reproduced in any form or by any means without the prior written consent of Vector. To the maximum extent permitted under law, all technical data, texts, graphics, images and their design are protected by copyright law, various international treaties and other applicable law. Any unauthorized use may violate copyright and other applicable laws or regulations. Copyright 2021, Vector Informatik GmbH. Printed in Germany. All rights reserved. 80403 User Manual CANoe/CANalyzer Option .Scope Table of Contents Table of Contents 1 Introduction 3 1.1 About this User Manual 4 1.1.1 Access Helps and Conventions 4 1.1.2 Certification 5 1.1.3 Warranty 5 1.1.4 Support 5 1.1.5 Trademarks 5 1.2 Product Overview 6 2 Installation 9 2.1 Software Requirements 10 2.2 Software Installation 10 2.3 Hardware Installation 11 2.3.1 Vector Scope Bus Probe Calibration 14 2.3.2 Scope Operations with VN8900, VT System and CANoe RT 15 2.3.3 Multi-Scope Operations 16 2.3.4 Scope Operations with CAN Disturbance Interface/FRstress 18 2.4 First Steps 19 © Vector Informatik GmbH Version 2.12 - I - User Manual CANoe/CANalyzer Option .Scope Introduction 1 Introduction In this chapter you find the following information: 1.1 About this User Manual page 4 Access Helps and Conventions Certification Warranty Support Trademarks 1.2 Product Overview page 6 © Vector Informatik GmbH Version 2.12 - 3 - Introduction User Manual CANoe/CANalyzer Option .Scope 1.1 About this User Manual 1.1.1 Access Helps and Conventions To find information The user manual provides you the following access helps: quickly > at the beginning of each chapter you will find a summary of its contents, > in the header you see the current chapter and section, > in the footer you see to which program version the user manual replies.
    [Show full text]
  • Vector: Eye Diagram Analysis for CAN FD
    Eye diagram analysis for CAN FD CAN FD CAN (Photo: Vector Informatik) Vector (Photo: The eye diagram is an analysis method for evaluating the signal quality of transmission networks. Eye diagram analysis can help finding corrupting influences on CAN networks. AN networks can transmit information bit by bit from Creation of a classical eye diagram Csender to partly distant receivers. The information transfer can, however, be easily corrupted by the network During the network design, a configuration for the phase topology, cable length between the participants, line and segments of the bit as well as their sampling points is terminating resistors as well as external electric influences. created separately for the arbitration phase and the data Both eye diagram analysis and serial bit mask analysis phase. According to the CAN protocol, one bit is time- allow these influences to be identified and corrected early divided into four segments: a synchronization segment, during the configuration phase of the CAN network. a segment for compensating time delays, and two phase Due to the higher and flexible bit-rate of the data segments, which compensate the phase errors of the bit phase, CAN FD is considerably more noise-sensitive than edges. The phase segments are often designated TSEG1 Classical CAN, which has a fixed bit-rate only for the entire and TSEG2. The TSEG 1 summarizes the first phase seg- frame. The transmission of CAN FD frames always begins ment and the compensation segment. Figure 1 shows the with the lower bit-rate of the arbitration phase. A switch to time division of a bit into the mentioned segments.
    [Show full text]
  • Real-Time Ethernet Residual Bus Simulation: a Model-Based Testing Approach for the Next-Generation In-Car Network
    Real-time Ethernet Residual Bus Simulation: A Model-Based Testing Approach for the Next-Generation In-Car Network Florian Bartols, Till Steinbach, Franz Korf, Bettina Buth, Thomas C. Schmidt HAW-Hamburg, Department Informatik Berliner Tor 7, D-20099 Hamburg, Germany {florian.bartols, till.steinbach, korf, buth, schmidt}@informatik.haw-hamburg.de ABSTRACT Keywords The increasing complexity of automotive networks, their Real-time Ethernet, TTEthernet, Residual Bus Simulation, challenging timing constraints and their high bandwidth de- Model-Based Testing, Validation, Modeling, UML-MARTE mands require new concepts for future in-car communica- 1. INTRODUCTION tion. Real-time Ethernet is meant to be a suitable candi- Today's cars are complex, mixed critical [20], distributed date for the next-generation in-car interconnection. How- systems with more than 70 electronic control units (ECUs). ever, model-based testing capabilities must be available as These units are responsible for information and entertain- well. Applications must be validated prior the first assem- ment systems, e. g. radio and navigation or safety critical bly, due to the distributed development process. Methods functions, such as emergency breaking or airbag systems. like residual bus simulation are of particular interest to allow The requirements for these systems include aspects such for testing systems in early development stages by emulating as bandwidth, reliable data transmission and real-time be- unfinished or not available parts of the system. havior in different combinations. While safety critical func- In this paper, we present a methodology and a feasibility tions have high demands on real-time characteristics, enter- study of a residual bus simulation in automotive real-time tainment components require high bandwidth capabilities.
    [Show full text]
  • • Mastery of Complexity: Development Systems
    18th International Congress and Exhibition October 18 – 19, 2017, Bonn Top Topics: Highly Automated Driving End-to-End E/E Architecture • Intelligence: data-based and artificial • Architecture: service oriented • Enablers: sensor systems to environment model • Key success factor: open and reusable • Validation: both virtual and real Günther H. Oettinger, Security European Commissioner for Smart & Connected Vehicles • Duty regarding points of weakness Dipl.-Ing. Uwe Michael, Budget & Human Resources, • From vehicle to back-end • Updating: over-the-air Director Electrics/Electro- European Commission, • The framework: software nics, Dr. Ing. h.c. F. Porsche Brussels, Belgium Sanjay Brahmawar, AG, Weissach General Manager, IBM Watson Internet of Things, Lighting Technology Munich E-Mobility 2025 • Matrix: intelligence in illumination • Voltage: 48 – 800 V • Charging: high-power and infrastructure Dipl.-Inf. Elmar Frickenstein, Methods + Testing Dipl.-Ing. (FH) Helmut Matschi, Senior Vice-President Fully ...!? • Function integration virtual Member of the Board, Interiors Automated Driving, Driver Offboard Ecosystems • Test coverage with self-learning systems Division, Continental AG, Assistance, BMW AG, Munich • Big data in the automotive sector Regensburg Dr.-Ing. Dirk Didascalou, UX Vice-President, IoT, Amazon Vehicle Wiring Systems 2025 #eliv Web Service, Seattle, USA • From cognitive transfer to augmented reality • Orientation: by zones • Human-machine interface: user-centered www.eliv-congress.com • Mastery of complexity: development systems Including up-to-date contributions from Conference by VDI Wissensforum GmbH | www.eliv-congress.com | Phone +49 211 6214-201 | Fax +49 211 6214-154 The most important branch meeting for experts in electronics ELIV – Program Overview 1st congress day Wednesday, 18 October 2017 Q 07:45 Registration Q 08:45 Opening of the Conference Dipl.-Ing.
    [Show full text]
  • Candb++ Manual
    CANdb++ Manual Version 3.1 English Imprint Vector Informatik GmbH Ingersheimer Straße 24 D-70499 Stuttgart Vector reserves the right to modify any information and/or data in this user documentation without notice. This documentation nor any of its parts may be reproduced in any form or by any means without the prior written consent of Vector. To the maximum extent permitted under law, all technical data, texts, graphics, images and their design are protected by copyright law, various international treaties and other applicable law. Any unauthorized use may violate copyright and other applicable laws or regulations. © Copyright 2019, Vector Informatik GmbH. Printed in Germany. All rights reserved. CANdb++ Manual Table of Contents Table of Contents 1 Introduction 4 1.1 Concept 4 1.2 About This User Manual 5 1.2.1 Conventions 5 1.2.2 Certification 6 1.2.3 Warranty 6 1.2.4 Support 6 1.2.5 Trademarks 7 2 Basics 8 2.1 Overview of CANdb++ 8 2.2 Datamodel of CANdb++ 9 2.3 Installation 9 2.4 Main Window 10 3 Tutorial 11 3.1 Tutorial Overview 11 3.2 Start the Program 11 3.3 Creating a New CAN Database 12 3.3.1 Copying Existing Objects 14 3.3.2 Creating New Objects 15 3.3.3 Modifying Existing Objects 16 3.4 Linking Objects 18 3.5 Display Communication Matrix 20 3.6 Value Tables 21 3.7 Assign Value Tables 22 3.8 Create User-Defined Attributes 23 3.9 Modify Values of User-Defined Attributes 24 3.10 Perform Consistency Check 26 4 API 27 4.1 INI Files 27 4.1.1 CANdb.ini 27 5 Glossary 29 6 Index 31 © Vector Informatik GmbH 3.1 - 3 - CANdb++ Manual 1 Introduction 1 Introduction 1.1 Concept All communication-relevant data that are processed in a networked CAN bus system as well as their interrelationships are usually administered in a central communications database.
    [Show full text]
  • Serial Bus Systems in the Automobile
    Serial Bus Systems in the Automobile Part 3: Simple and cost-effective data exchange in the automobile with LIN In just a very short time the LIN bus has established itself as the technology of choice for simple and cost-effective data exchange in the automobile. Today, many automotive OEMs are relying on LIN to transmit non-critical signals in the body/convenience area. The following article points out the reasons for the victory of LIN (Local Interconnect Network) in the automobile and explains the underlying technology. Why another data bus in the automobile? standard for the sensor/actuator area. With definition of a simple Growing demands of car users for driving conveniences have led to and cost-effective Physical Layer based on ISO standard 9141, as wide-ranging electronification in this area of vehicle technology. well as a simple and lean communication protocol, the LIN Consor- This is reflected in the migration of numerous electronic compo- tium has laid the foundation for success. It set the stage for imple- nents into the convenience area. For a long time it was usual prac- mentation of simple and cost-effective bus nodes. tice to interconnect the continuously increasing number of sensors, actuators, stepper motors and DC motors directly to a central con- The LIN Consortium not only focused on LIN communication itself, trol module. but also provided a development methodology (LIN Work Flow), and This trend gradually met with criticism: It led to a rapid increase in this furthered acceptance of the bus system in the automotive in- wiring costs, along with greater space requirements, increasing dustry significantly.
    [Show full text]