Holger Zeltwanger. The OSI model

Transcription

1 Holger Zeltwanger A personal review and an outlook The OSI model Text (application software) Vocabulary + phrases * Grammar rules (Translation services) (Start and stop indications) (Page numbering) (Routing) Normally not used in singlesegment networks Character set Paper, pen, or laser-beam * Including confirmation and encryption procedures

2 First transceivers output v p to 100 ma (cur te: The electrical parameters for pin yer". They are not yet agreed upon by the G Mechanical Parameters The connector used to plug electronic modules to the bus line is a 9-pin D-Sub conn /4/. Its pinning is fixed as follows Pin Signal Description 1 - Reserved 2 _L _L bus line (dominant low) 3 _GND Ground 4 - Reserved 5 (_SHLD) Optional Shield 6 (GND) Optional Ground 7 _H _H bus line (dominant high) 8 - Reserved (error line) CiA 102 (_V+) Optional external positive supply (dedicated for supply of transceiver and optocouplers, if galvanic isolation of the bus nodes applies) 9 node has to provide a male connector, meeting the above-mentioned specification., pin 3 and pin 6 have to be interconnected. dules providing two bus connections, and inside the T-connectors, all the ave to be connected. The intention is, that there shall be no e, assuming a possible future specification of the use nical isolation, the necessity of an e se. 15 of 35 members exhibited on the first CiA joint booth show at Interkama 1992 physical layer options u ISO 11898:1993 High-speed transceiver u ISO :1994 Low-speed transceiver u SAE J2411:2000 Single-wire transceiver u ISO :2003 High-speed transceiver u ISO :2003 Truck/trailer transceiver u ISO :2006 Low-power/low-speed transceiver u ISO :2007 Low-power/high-speed transceiver u ISO :2013 Selective wake-up transceiver u ISO :2016 Up to 5-Mbit/s transceiver Lessons learnt: (1) Separate strictly MAU (medium access unit) specifications from device and network system design recommendations or specifications. (2) Don t specify additional functions in separate documents.

3 (FD) network design u SAE J1939-1X high-speed (250 and 500 kbit/s) u SAE J high-speed (125 kbit/s) u SAE J high-speed (250 kbit/s) u SAE J high-speed (500 kbit/s) u SAE J high-speed (2 Mbit/s) u SAE J high-speed (5 Mbit/s) u ISO diagnostic network requirements u ISO Truck/trailer point-to-point network u ISO ISOBUS network specification u CiA 301/303 open network design rules u IEC DeviceNet network specification u Arinc 825 (FD) for airborne u CiA FD recommendations u CiA FD reference topology examples What comes next? u Smart transceivers with additional functions such as selective wake-up (already available), security, filtering of FD frames, dynamic ringing suppression, etc. u FD transceivers supporting bit-rates higher than 5 Mbit/s. u FD network systems using bus-line topologies running at bit-rates higher than 2 Mbit/s.

4 data link layer norm u ISO 11898:1993 data link layer with 11-bit IDs u ISO 11898:1995 amendment Extended frame format u ISO :2003 data link layer u ISO :2015 data link layer with FD Lessons learnt: (1) Original names such as 2.0 will survive for a long time. Official references such as ISO need a long time to be accepted and used in datasheets some parties will never use them. (2) Even when submitted for international standardization, prove first the functionality and features before implement them (this is not just true for data link layer protocols). (3) To standardize the host interface is nearly impossible, but the minimum functional behavior is standardized (see CiA and CiA 603). What comes next? S p(t) Standard bits bits D D R D R R A p S p(t) 1V Q s(t) 1V A P 3.5V Q d(t) 2.5V Closes for D bit 1.5V Q s(t) Some South Korean scientists have introduced a multi-level modulation scheme to be used just in dominant bits. This approach allows bit-rates of over 100 Mbit/s and can run Classical communication simultaneously with no impacts.

5 Transport layer protocols u CCP ( Calibration Protocol) u SDO (Service Data Object) protocols (open) u Explicit Messages (DeviceNet) u BAM and CTS (J ) u ISO (ISO-TP) u XCP (Extended Calibration Protocol) u etc. Lessons learnt: (1) Each application domain likes to re-invent transport layer protocols. This means, up to today this lesson has not been learnt (this is sometimes also true for other higher-layer protocols). (2) Specify a byte-oriented instead of a bit-oriented protocol overhead (see the new USDO protocol for open FD), this simplifies implementations. Migrating to FD u ISO :2016 Transport protocol and network layer u ISO :2016 Diagnostic PDU API u ASAM XCP version 1.2 Extended calibration protocol u open FD Universal Service Data Object (USDO) u Arinc 825 FD transport layer Lessons learnt: Migrating transport layer protocols from Classical to FD data link layer is not a big deal. If done properly, you can introduce in the past missed new features such as broadcast and multicast, routing, functional addressing as well as session identification overcoming the historical limitations.

6 What comes next? The different transport layer protocols will survive, no harmonization will happen due to the installed base and the requirement of backwards compatibility. But you may surprise me. Time-triggered u ISO :2004 TT specification Lessons learnt: TT was too late and appeared, when TTP (time-triggered protocol) and FlexRay were already adapted by OEMs, even if they were still under development. Although TT was earlier standardized internationally, the automotive industry continues to use FlexRay for some timetriggered applications. Other industries used time-triggered software solutions based on Classical.

7 What comes next? Perhaps somebody combines FD and TT. But you may surprise me. The so-called Fieldbus war A-bus Arcnet Arinc 629 Arinc 825 AS-interface Bitbus Controlnet CAL aerospace Kingdom open DeviceNet DIN-Messbus EIB FIP FF Flexray Hart Monument to the Battle of the Nations Interbus Isobus J1939 LIN Mil-std-1553 LON Modbus MVB P-Net Profibus Safetybus p SDS Sercos Seriplex Spacewire Suconet TTP etc.

8 Application layer protocols u 1992: Application Layer (CiA 200 series) u 1994: open (CiA 301, EN :1999) u 1994: DeviceNet (ODVA, IEC :2014) u 1994: J (SAE) u 1999: (ISO)* u 2000: NMEA 2000 (IEC :2008)* u 2002: ISOBUS (ISO :2002)* u 2007: 825 (SAE/ARINC) * Based on J Lessons learnt: Application layers developed for based networks provide very similar services. This means we re-invented several times the wheel. The main differences are in the flexibility of the provided services. The most flexible approach covers also the more strict (limited) once. What comes next? Hopefully, no additional -based application layer approach will be invented!

9 Conformance testing u Since 2004, the data link layer conformance test plan has been standardized in ISO u For the physical layer, the ISO test plan has been standardized. u In the meantime, for some of the -based higher-layer protocols conformance test plans have been developed. Lessons learnt: (1) Conformance testing is like spell-checking in human communication. It does not guarantee communication interoperability. (2) Different conformance test plan implementations may lead to different test results. Interoperability testing u Communication and application interoperability testing can be achieved by so-called plugfests. u Another option is a golden system. Lessons learnt: (1) Interoperability is always just valid for a dedicated test system. (2) System designers should be interested in components and devices tested on interoperability. (3) Component suppliers are interested in interoperability tests; device makers are normally not that overwhelmed about interoperability testing. (4) We would need internationally standardized interoperability test plans (for Automotive Ethernet they are planned for the physical layers).

10 Mixing of OSI layers u You can use different physical layers for Classical networks. u You can use different data link layers for the higher-layer protocols originally developed for -based networks. Lessons learnt: (1) open was adapted by Ethercat, Powerlink, Safetynet, and Varan*. Unfortunately, some application layer services have been changed, which reduced the communication interoperability. (2) Middleware such as AUTOSAR hides the application layer protocol differences, but increases the software overhead. * The DeviceNet application layer (CIP) is also used by ControlNet and Ethernet-IP Communication profile u Dedicated specifications for all implemented OSI layers are to be defined. u Dedicated layer setting services (e.g. setting the bit-rates or assigned node-ids) could be added. u Additional generic device parameters (e.g. vendor- ID, specification version, product name, device temperature, etc.) could be added. Lessons learnt: In order to achieve communication interoperability of devices, we need to implement in all devices the same layers and optional functionality. But this still doesn t guarantee interoperability on the application level.

11 Functional safety sub-layer u The first -based functional safety protocols were developed in the late 90ties (ESALAN, SafetyNet p, etc.). u open Safety was the first open -based functional safety protocol, which was implemented even in a single micro-controller achieving SIL-3 approval by German TÜV. It was internationally standardized in EN u CIP Safety can be used on DeviceNet and other communication systems (e.g. Ethernet-IP and Sercos). u SAE J1939 committee is still developing a functional safety protocol, while ISOBUS has a solution with some tradeoffs. Lessons learnt: (1) A simple functional safety protocol is not sufficient. You also need to develop an ecosystem. (2) It took a long time to establish open Safety (about 15 years). Cyber security sub-layer u There are a lot of proprietary cyber security approaches suitable for -based networks, none is standardized yet. u Most of them come from the IT world and are related to the higher-layer protocols. Lessons learnt: is often blamed as unsecure, but this is if you would blame a door without a lock not to be safe. Nevertheless, we need a standardized cyber security for based networks so-to-say with a lock.

12 What comes next? u We need a common functional safety protocol, so that in applications with heterogeneous communication systems an end-to-end protection can be achieved even beyond single networks. u We need a common cyber security protocol for authentication on different layers. u We need to combine functional safety and cyber security. This will be only possible, when using FD. Device profile specifications u In order to achieve application interoperability in industrial control systems, ODVA has standardized device profiles for DeviceNet. u CiA has done the same for open-based industrial control systems and some other application fields (e.g. medical electronics and mobile machines). Lessons learnt: (1) Device profile specifications are always a compromise. They should be strict to achieve a high-level of application interoperability and they should provide sufficient freedom to allow designing scalable products and to extend the functionality manufacturer-specific. (2) Device profiles improve the application interoperability, but still require some device configuration and are mainly suitable for master/slave control system.

13 Application profiles u Application profiles have been developed for example for J1939- based networks (e.g. SAE J , NMEA2000 (IEC ), and ISO also known as ISOBUS) u For open several application profiles have been specified (e.g. CiA 417 also known as open Lift, CiA 420 for extruder downstream devices, CiA 422 also known as CleANopen, CiA 447 for special-purpose cars, CiA 454 for battery management). Lessons learnt: Application profile approaches enable designing network systems without device configuration (off-theshelf plug-and-play), when just the default mandatory functionality is used. But even in case of using optional functions, the configuration effort can be reduced to a minimum. On the other hand, devices compliant to a dedicated application profile can t be used in other domains. Network engineering u Standardized electronic data sheets (EDS) or other machine-readable representation of devices (ECU) are necessary as standardized exchange formats between tools from different vendors. u Standardized layer setting services simplify system design or device configuration. Lessons learnt: (1) XML-based EDS/ODX are proper solutions. But some industries are very conservative and have not yet adapted XMLbased open EDS. (2) Layer setting services for example for bit-rate configuration and dynamic node-address assignments are used just in a few applications.

14 Standardized gateways u CiA has developed the CiA 309 interface profile specification series to access open networks from Ethernet-based networks (e.g. ModbusTCP or ProfinetIO). u CiA has developed the CiA 413 series of interface profiles for gateways linking open and J1939-based networks. u CiA has developed interface profiles for open gateways to RFID (CiA 445), AS-interface (CiA 446) and wireless networks (CiA 315, CiA 812). Lessons learnt: (1) Using the very same application layer mapped to different data-link layers avoids the definition of interface profiles. (2) Also Middleware such as AUTOSAR encapsulating different communication protocols avoid the definition of interface profiles, however this adds another software layer requiring processing and memory resources. Industry 4.0 and OPC UA/TSN u German machine builders force industrial automation suppliers to use OPC UA communication systems including standardized device data models. If used in real-time applications, the TSN (time sensitive network) data link layer is required (under development in IEEE). TSN is also a candidate for Automotive Ethernet. u The OPC UA communication networks are like a relay station between embedded as well as deeply embedded control networks and the clouds processing the big data. This is IoT or IIoT. Lessons to be learnt: In order to achieve application interoperability in heterogeneous network systems, device and application profiles need to be standardized bus-independently. CiA had proposed this for industrial control systems already in 2004 (nickname: ProOpen). We were more than one decade too early.

15 Summary Lessons learnt: u We should not specify requirements to be implemented by different parties (chipmakers, device suppliers, system designers) in the same document. u We should write specifications and standards as implementationindependent as possible. u We should try to reuse already standardized protocols and do not reinvent wheels looking even to other application domains. u We should not stop standardization before we have achieved application interoperability in heterogeneous communication network systems. u We should standardize conformance and interoperability test plans for all communication layers and for profiles. u We should be patient: Sometimes standardization requires a long breath; and in some cases, we might be too early or too late. We are not at the end! There are still a lot of things to do!