The 7 Layers of the OSI Model Applied to Automotive Protocols

The OSI Model

The OSI model (Open Systems Interconnection) is a conceptual framework representing how various elements within a networked system communicate. The OSI model divides this intra-element communication process into seven distinct conceptual layers, each with specific responsibilities.

Software that manages the communication between the various elements of a networked system are all based on various communication protocols, which are themselves based on the OSI model.

A specific communication protocol may only cover a few layers of the OSI model, and so it isn’t uncommon for communication software to be developed in line with a “stack” of various communication protocols, combined.

These networked system communication protocols and the OSI model itself are internationally recognized.

The OSI Model applied to Embedded Systems

While there are plenty of resources that describe the OSI model in general, as Simma Software primarily develops communication software for automotive embedded systems, this article will focus on how the OSI model applies to the embedded systems space specifically.

By understanding the functions of each layer of the OSI model, embedded systems engineers can better orient themselves to the various embedded system communication protocols, as well as make more informed decisions regarding hardware design, communication protocol selection, and software architecture.

Below are the 7 layers of the OSI model, described in detail as they apply to embedded systems.

1. The Physical Layer

• Purpose: The physical layer defines the electrical, mechanical, and procedural characteristics necessary to establish, maintain, and deactivate physical connections. It determines how bitstreams are transmitted over physical components (listed below). The physical layer is typically handled by the electronics circuit or the microcontroller itself.
• Components: Typically, in embedded systems, these are hardware components like cables (coax, fiber, etc.), transceivers, connectors, and antennas.
• Key Challenges: signal quality and integrity, noise reduction, physical space constraints, and minimizing power consumption.
• Protocols used: LIN, CAN, and Ethernet each define their own physical layer requirements.
  • LIN is ideal for less critical applications and can work over a 12V electrical system. It’s also ideal in a situation where information needs to be transmitted over a single wire. A LIN transceiver interfaces the LIN protocol controller with the physical bus, converting data into signals suitable for transmission and vice versa.
  • CAN uses differential signaling to transmit data. This means it sends two opposite-polarity signals over two wires, which helps reduce noise and improve data integrity. In CAN, bits are represented as dominant (logical 0) or recessive (logical 1) states. This is a method of ensuring that the signal can be accurately read even in noisy environments. A CAN transceiver handles the conversion between the CAN controller’s signals and the differential signals on the bus.
  • Ethernet is widely used in modern automotive networks for high-speed data transmission. It operates on various physical media such as twisted pair cables, fiber optics, etc. An Ethernet PHY (Physical Layer) chip is responsible for managing the physical connection and data encoding/decoding for Ethernet communication.

2. Data Link Layer

• Purpose: The data link layer ensures reliable data transfer across the physical layer and detects and corrects errors that may occur.
• Responsibilities:
  • Handling the interaction with the underlying physical medium.
  • Frame formatting (defining the structure of data packets for transmission).
  • Error detection and control using algorithms like CRC.
  • Flow control management, regulating data flow to avoid buffer overflows, and
  • Handling physical addresses for device identification.
• Key Challenges: Minimizing power usage, memory footprint, and processing power while still performing tasks above.
• Protocols used: CAN, LIN, and Ethernet are protocols that are used in this layer that each define their own data link requirements. Each of these protocols will package information into “data link layer frames” differently.
  • CAN: Classical CAN and CAN FD are two common datalink layer protocols. A frame format contains CAN Identifier, DLC, Payload and CRC.
  • LIN: Has a single master node and one or more slave nodes. The master node transmits the header, which contains a break, synchronization field, and identifier field. The slave nodes respond with data based on the header information.

3. Network Layer

• Purpose: The network layer handles the routing of data packets from the source to the destination across multiple nodes and networks. It provides logical addressing and path determination.
• Responsibilities:
  • Packet encapsulation: Adds header information (source/destination addresses, protocol, etc.) to data.
  • Packet routing: Selects appropriate paths for packet forwarding based on routing tables.
  • Error handling: Detects and reports packet loss or errors.
  • Address resolution: Maps logical addresses (IP addresses) to physical addresses (MAC addresses).
• Key Challenges: Network layer challenges in embedded systems arise from limited resources, real-time requirements, security vulnerabilities, unreliable networks, and specific application demands. To address these, embedded systems often use lightweight protocols, prioritize energy efficiency, implement robust security, and adapt to network conditions.
• Protocols used:
  • IP (Internet Protocol): While not as prevalent as in traditional networking, IP is gaining traction in automotive networks, especially with the rise of connected and autonomous vehicles. It provides a standard way to address devices and route data packets within the vehicle. IPv4, IPv6, ICMP (used for ping), and IGMP are all IP protocol variants used in this layer.

4. Transport Layer

• Purpose: The transport layer is responsible for end-to-end communication, ensuring complete data transfer with error recovery and flow control. In embedded systems, this layer often uses simplified or customized protocols to meet specific application requirements.
• Responsibilities:
  • End-to-end data delivery: Ensuring reliable data transmission between applications.
  • Congestion control: Managing data flow to prevent network overload.
  • Error recovery: Detecting and correcting data transmission errors.
  • Flow control: Regulating data flow to match receiver’s processing capabilities.
  • Multiplexing: Combining multiple data streams into a single channel.
  • Connection management: Establishing, maintaining, and terminating connections.
• Key Challenges: Implementing the Transport Layer in embedded systems is hindered by stringent resource limitations, the imperative for real-time performance, the need for robust operation in harsh environments, security challenges posed by limited resources, power optimization demands, the necessity to adapt standard protocols, and the requirement for seamless integration with diverse networks and devices.
• Protocols used: 
  • TCP (Transmission Control Protocol): Provides reliable, connection-oriented communication, ensuring data integrity and order. Often used in applications requiring high reliability, such as file transfers or remote login.
  • UDP (User Datagram Protocol): Offers connectionless, unreliable data delivery with minimal overhead. Suitable for real-time applications or when data loss is acceptable, such as streaming audio or video.
  • CAN (Controller Area Network): Operates at the data link layer but provides some transport layer functionalities like error detection and retransmission. Offers deterministic communication with low latency, making it suitable for critical real-time systems.  ISO 15765-2 defines the CAN TP (transport protocol) requirements.
  • LIN (Local Interconnect Network): Simpler protocol with limited error checking compared to CAN. ISO 17987-2 and LIN specs define the LIN TP requirements.

5. Session Layer

• Purpose: The session layer manages sessions between applications, establishing, maintaining, and terminating connections. In embedded systems, this layer ensures that communication sessions can be managed effectively, particularly in systems that require continuous or periodic data exchange.
• Responsibilities:
  • Session establishment and termination: Initiating, managing, and closing communication sessions between devices.
  • Data transfer: Ensuring reliable and ordered delivery of data between endpoints.
  • Flow control: Managing data flow to prevent congestion and buffer overflows.
  • Security: Providing basic security mechanisms like authentication.
• Key Challenges: Implementing the session layer in embedded systems is challenging due to limited resources, real-time constraints, power consumption concerns, security trade-offs, interoperability issues, error handling complexities, protocol overhead, and rigorous testing requirements.
• Protocols used:
  • Unified Diagnostic Services (UDS): Within the session layer, UDS would cover the functionality related to communication sessions, authentication and timeout handling.
  • J1939 does not define a session layer in the same sense as the OSI model. The protocol relies on its transport and application layers to handle message delivery, but without the explicit session initiation, management, or termination mechanisms found in UDS or TCP.
    

6. Presentation Layer

• Purpose: The presentation layer translates data between the application layer and the lower layers, ensuring that data is in a usable format. This includes data encryption, compression, and translation. For embedded systems, this layer handles data encoding and decoding in a manner that optimizes memory usage and processing power.
• Responsibilities:
  • Compression / decompression
  • Encoding / decoding
  • Encryption / decryption
  • Serialization / deserialization
• Key Challenges: Key challenges in the presentation layer of embedded systems stem from the need to balance user experience with hardware constraints. Limited resources, real-time performance requirements, power consumption limitations, and the complexities of software development all contribute to the challenges of creating effective and robust human-machine interfaces in this environment.
• Protocols used:
  • The protocols that are used in this layer are heavily application dependant. 

7. Application Layer

• Purpose: The application layer is the topmost layer, providing end-user services and interfaces. In embedded systems, this layer encompasses the specific applications and services running on the device, such as sensor data processing, control systems, and user interfaces. The application layer protocols in embedded systems are designed to be lightweight and efficient, ensuring that the system can perform its intended functions within the constraints of the hardware.
• Responsibilities:
  • Direct interaction with the user: Provides application programming interface (API) to develop custom applications and input/output handling.
  • System-specific tasks: Performs core functions of the embedded system (e.g., motor control, data acquisition, image processing).
  • Network communication: Handles data exchange with other systems or devices.
  • Data management: Stores and retrieves system data, configuration, and logs.
  • Error handling and recovery: Manages system failures and provides recovery mechanisms.
• Key Challenges: Developing application layer software for embedded systems is fraught with challenges, including stringent resource limitations, the imperative for real-time performance, ensuring reliability in harsh conditions, safeguarding sensitive data, optimizing power consumption, accommodating diverse hardware and software components, and rigorously testing and debugging within tight development schedules, all while prioritizing user experience and managing escalating software complexity.
• Protocols used:
  • J1939 is a protocol used primarily in heavy-duty vehicles for communication between electronic control units (ECUs). At the application layer, J1939 defines how data is structured and exchanged between devices. It standardizes the messaging format for diagnostics, control, and information sharing, ensuring that different ECUs can communicate effectively within a vehicle network.
  • UDS (Unified Diagnostic Services): UDS is a protocol used for diagnostics in automotive systems. At the application layer, UDS defines the services and commands that can be used to perform diagnostics, such as reading fault codes, programming ECUs, or monitoring sensor data. It allows a diagnostic tool to communicate with the vehicle’s ECUs to diagnose and manage vehicle functions.
  • XCP (Universal Measurement and Calibration Protocol): XCP is a standardized communication protocol used in the automotive industry to develop and optimize electronic control units (ECUs). It facilitates real-time access to ECU parameters and data, enabling engineers to measure ECU variables and system performance, calibrate ECU parameters to optimize vehicle behavior, and stimulate ECU inputs for testing and validation.

Conclusion

• Understanding the OSI model in the context of embedded systems is crucial for designing efficient, reliable, and secure communication protocols.
• Each layer of the OSI model plays a specific role in ensuring data is transmitted accurately and effectively, even within the constrained environments typical of embedded systems.
• By carefully considering the challenges and responsibilities associated with each layer, engineers can make informed decisions that optimize hardware and software design, leading to better-performing and more robust embedded solutions.
• This layered approach not only enhances the interoperability and scalability of embedded systems but also ensures that they can meet the specific demands of various applications, from industrial automation to IoT devices.