Table of Contents Why Was the CAN Protocol Introduced? Let’s start from the basics: why did we need the CAN protocol in the first place? Imagine the electronics in a car before CAN was introduced. Each part of the car’s electronics had to be directly wired to every other part it needed to communicate with. This point-to-point wiring system had some big problems: Too Many Wires: As cars got more advanced, they needed more electronic control units (ECUs) to handle all the new features. Each new feature meant adding more wires, making the system very complicated and heavy. High Costs: More wires didn’t just mean more complexity; it also meant higher costs. Building and maintaining such a complicated wiring system was expensive, and finding and fixing problems in all those wires took a lot of time and money. Hard to Expand: Want to add a new feature to the car? That meant even more wires and changes to the existing setup, which was a real headache. The system wasn’t built to easily handle new additions. Interference Problems: With so many wires, there was a lot of electromagnetic interference (EMI). This interference could mess up the signals being sent through the wires, making the whole system less reliable. Explaining the CAN Protocol The Controller Area Network (CAN) is a robust protocol for connecting electronic control units (ECUs) in vehicles and other distributed systems. CAN was introduced to address the need for a more efficient, reliable, and flexible communication system in automotive applications. Let us explore how CAN works, starting with its fundamental layers. The Physical Layer of CAN The physical layer of CAN consists of a two-wire bus system called CAN_H (high) and CAN_L (low). Data is transmitted differentially, meaning the voltage difference between the two wires represents the actual data. This approach provides excellent resistance to noise and interference, ensuring reliable communication among all nodes on the network. Data Link Layer in CAN The data link layer is responsible for managing the data exchange between nodes on the CAN network. It consists of several key functions: Framing: CAN frames consist of several fields, including the identifier, control, data, CRC, ACK, and end of frame. These fields structure the data and control information for transmission. Addressing: Instead of traditional addresses, CAN uses message identifiers for addressing. Each message has a unique identifier that determines its priority and relevance to nodes on the network. Error Detection: CAN employs multiple error detection mechanisms, such as the Cyclic Redundancy Check (CRC), acknowledgment checks, and form checks. If an error is detected, the erroneous message is discarded, and an error frame is transmitted. Arbitration: When multiple nodes attempt to send messages simultaneously, CAN uses a non-destructive bitwise arbitration process. The message with the highest priority (lowest identifier value) wins the arbitration and continues transmission, while others wait for the next opportunity. Importance of Synchronization Synchronization is critical for the correct operation of the CAN network. To achieve this, all nodes synchronize their clocks at the start of each message transmission and continuously resynchronize throughout the message. This synchronization ensures that all nodes interpret the bit timings accurately and maintain a consistent understanding of the message. Hard synchronization occurs at the beginning of every message. When a node receives the start bit, which is indicated by a transition from recessive to dominant, it aligns its clock with that transition. Resynchronization happens throughout the entire message. As the message is being sent, nodes continually adjust their clocks based on the expected bit timings. If a node detects that a bit transition occurred earlier or later than expected, it adjusts its internal clock to stay in sync with the others. Exploring the Versions of CAN Protocol The Controller Area Network (CAN) protocol has evolved over time, leading to various versions, each offering enhancements over its predecessors. Here, we’ll overview the different CAN versions, with a primary focus on CAN 2.0. Versions of the CAN Protocol 1. CAN 2.0A (Standard CAN) Identifier Length: 11 bits Message Size: Up to 2,048 unique message IDs Data Speed: Typically up to 1 Mbps Features: Standard data frames and error detection mechanism. 2. CAN 2.0B (Extended CAN) Identifier Length: 29 bits Message Size: Up to 536 million unique message IDs Data Speed: Typically up to 1 Mbps Features: Extended identifier field for more complex applications. 3. CAN FD (Flexible Data Rate) Enhanced Data Rate: Supports faster data transmission rates, up to 8 Mbps Data Length: Up to 64 bytes of data per frame Features: Flexible data rate and extended data field for more efficient communication. 4. CAN XL Higher Bandwidth: Supports even faster data rates, exceeding 10 Mbps. Extended Data Length: Capable of handling larger amounts of data Features: Improved protocol efficiency and higher performance for demanding applications Focus on CAN 2.0 While all versions of CAN offer unique advantages, our primary focus will be on CAN 2.0, the foundation of the CAN protocol. CAN 2.0A (Standard CAN) CAN 2.0A FRAME STRUCTURE OVERVIEW 1. Arbitration Field The Arbitration Field is crucial for determining the priority of the message during arbitration: SOF(Start of Frame); 1 bit Determines the starting Identifier: 11 bits Uniquely identifies the message. Lower values have higher priority. RTR (Remote Transmission Request): 1 bit Indicates if the frame is a data frame (0) or a remote frame (1) requesting data. 2. Control Field Reserved bit: 2 bits DLC (Data Length Code): 4 bits Specifies the number of data bytes (0 to 8) in the Data Field. This allows the receiver to know how many bytes to expect. 3. Data Field Data Field: 0 to 8 bytes Contains the message content. 4. CRC Field CRC (Cyclic Redundancy Check): 15 bits For error checking of the Data Field. CRC Delimiter: 1 bit (recessive). 5. Acknowledgment Field ACK Slot: 1 bit (dominant if the frame is received correctly). ACK Delimiter: 1 bit (recessive). 6. End of Frame End of Frame: 7 bits (recessive). 7. Interframe Space Interframe Space: Variable recessive bits. Interframe Space and
Autosar Layered Architecture
Overview In a car at a time more than 100 small or large electronic subsystems are present. Most of these subsystems are connected directly or indirectly in one way or another. Now virtualize that this is a car and it has an Airbag control system which is controlled according to the vehicle motion monitoring system. If Vehicle motion experiences a sudden break or impact, the Airbag control system will be turned on. For understanding, let’s say the Airbag control system is Node A and the Vehicle motion monitoring system is Node B. Node B is situated at the front of the car and Node A is distributed on every seat of the vehicle. So Node B and Node A are connected directly to each other. But let’s say now there is one more Node C. Node C is a car Backlight. Now Node C and Node B are connected in a way if the vehicle motion experiences a sudden break then the car’s backlight has to be turned on immediately. As Car’s backlight is at the back, Node C is at the back of Car and Node B is at the front of the car, so we have to connect Node C and Node B also. Now wiring to connect to Node B and Node C would be required more to take it from front to back. Whereas if we place Node B at the center of the car, then the connection of Node A and Node C would be comparatively easy to do and fewer wires would be used. You can see the electronic subsystems used in cars are distributed across the vehicle. The arrangement of these electronic sub-systems, their architecture of placement and connection is what going to be the topic of today’s video. How the car electronic subsystems are connected, is what is gonna be the topic of today’s video. Surrounded by large-scale technological requirements (ADAS, connected vehicles, Software Defined Cars, Vehicle to Vehicle, Electrification, etc.) established OEMs and semiconductor companies are innovating and differentiating via the architecture designs for the arrangement of these electronic subsystems in a car. In the last video/blog, we learned about different electronic/electrical sub-systems that are there in the car. Now we are going to dwell on architecture on how the different electronic/electrical sub-systems are arranged in an automotive vehicle. What is E/E Architecture E/E architecture is the terminology for arrangmant of elecrical/electromcnis used in car. E/E Architecture organizes and integrates a vehicle’s electrical and electronic systems, including hardware and software components, to ensure they all work together seamlessly. E/E Architecture involves the design of the arrangement of electrical and electronic systems that control various functions of a vehicle, such as a powertrain, safety systems, infotainment, climate control and etc. E/E architecture is also termed as vehicle architecture. The E/E architecture is an arrangement of different components of a vehicle, all combine to make up the vehicle architecture. These components are : 1) electronics hardware 2) network communications 3) software applications, and 4) wiring involved to connect different electric/electrical sub-parts of the system. Why is E/E Architecture or Vehicle Architecture needed? Okay so now we have understand what is E/E architecture, now lets dwell into why do we need E/E architecture concept in automotive vehicle;s. Integration of computing technology into every aspect of the car has transformed how automotive OEMs approach design, engineering and manufacturing of automotive electrical sub-systems. Concurrently, the introduction of sensors into the vehicle architecture further accelerated the need for greater computing power to process and analyze the resulting data. The advancement toward connected cars led to a divergence in how carmakers approached the communication architecture of a vehicle’s electronics. The result of this innovation and integration is a tremendously complex system of electronic control units (ECUs), sensors, actuators, and wiring to connect it all together. The size and complexity of these architectures create new challenges for automotive OEMs and their suppliers. In this environment, the importance of the underlying E/E architecture is paramount. The new generation of automotive consumers expect constant internet connectivity, a fully customizable driving or riding experience, as well as personalized entertainment and functionalities. Simultaneously, consumers expect to feel safe and secure, while enjoying the latest, modern features on-demand, in real-time and over-the-air as they download different applications and services from vehicle “app-stores”. In fact, the vehicle is no longer the focal point in the consumer’s mind, rather it is the mobility service or mobility experience that it provides. Different aspects of E/E architecture are sensors, microcontrollers/processors, networking protocols, wiring and power distribution. All aspects of the E/E architecture occupy a larger role in enabling core vehicle functionalities. As a result, all aspects have grown in sophistication to meet these increased demands. Microcontrollers/processors have become more powerful to process the data coming in from larger sensor arrays using increasingly capable software. Meanwhile, vehicle networks have to manage the communications in this intricate system of sensors and controllers. The result of these innovations and integration is a tremendously complex system of electronic control units (ECUs), sensors, actuators, and wiring to connect it all together. The size and complexity of these electrical/electronic subsystems create new challenges for automotive OEMs and their suppliers. These challenges will only become more intense as companies continue to advance vehicle technologies, particularly in the automated driving space. In this environment, the importance of the underlying E/E architecture is paramount. Surrounded by large-scale technological change, have forced established OEMs to innovate and differentiate via the E/E architecture for automotive sub-systems. This means creating architectures that are scalable across vehicle platforms, flexible to future technologies, and reliable over extended lives in the field. Types of E/E Architecture There are 3 types of E/E architecture in automotive: Flat architecture Domain Architecture Zonal Architecture Up until the past decade, vehicle electronics used a flat architecture where embedded ECUs operated together in a limited way. Flat Architecture: In the context of automotive electronics, a flat architecture refers to a system where embedded electronic control units (ECUs) act
How does CAN Peripheral in Microcontroller work? In this blog get to know important concept of how CAN protocol is implemented in Microcontrollers
Overview So, hello guys, and welcome back to the Gettobyte Automotive Technology series of blogs. In today’s blog, we are going to dig into different electrical/electronic sub-systems used in Automotive. The automotive industry is today the sixth largest economy in the world, producing around 70 million cars every year and making an important contribution to government revenues all around the world. Automotive Vehicles are no longer mechanical systems, they are one of the largest consumers of Semiconductor chips like microcontrollers, microprocessors, ASIC’s, Integrated Circuits, embedded hardware, and Software solution around these semiconductor chips.  Infact at a time in a modern automotive vehicle there are more than 1000’s of Integrated Circuits and more then 1 lakh lines of code running in vehicles. Indeed, since then, the sector of embedded electronics, and more precisely embedded software, has been increasing at an annual rate of 10% in automotive industry. Electronic technology has made great strides and nowadays the quality of electronic components—performance, robustness, and reliability—enables use of them even for critical systems. At the same time, the decreasing cost of electronic technology allows them to be used to support any function in a car. Furthermore, in the last decade, several automotive-embedded networks such as local interconnect networks (LIN), Controlled Area Network (CAN), TTP (Time-Triggered Protocol), FlexRay and Ethernet were developed. Multimedia and telematic applications in cars are increasing rapidly due to consumer pressure; a vehicle currently includes electronic equipment like hand-free phones, audio/radio devices, and navigation systems. For the passengers, a lot of entertainment devices, such as video equipment and communication with the outside world are also available. These kinds of applications have little to do with the vehicle’s operation itself; nevertheless, they increase significantly as part of the software included in a car. Examples of these facts: Volkswagen Phaeton electronic sub-systems In 2004, the embedded electronic system of a Volkswagen Phaeton was composed of more than 10,000 electrical devices, 61 microprocessors, 3 controller area networks (CAN) that support the exchanges of 2500 pieces of data, several subnetworks, and one multimedia bus. In the Volvo S, inter-car network support the communication between the microprocessors controlling the mirrors and controlling the doors, for example, the position of the mirrors is automatically controlled according to the sense of the near-by vehicle and the volume of the radio is adjusted to the vehicle speed, information provided, by the antilock braking system (ABS) controller. Volvo S Electronic Sub-System In a recent Cadillac, when an accident causes an airbag to inflate, its microcontroller emits a signal to the embedded global positioning system (GPS) receiver that then communicates with the cell phone, making it possible to give the vehicle’s position to the rescue service. These are just a few examples, but there are many more that could illustrate this very large growth of embedded electronic systems in modern vehicles. Now in This blog, we are going to dip deeper into these electronics sub-systems in an automotive vehicle. What are functional domains in Automotive? To get a hierarchical understanding of the electronics used in a car, one can divide the car into different parts. These parts are basically in the car termed as Domains. According to the European ITEA EAST-EEA project, a domain is defined as, a sphere of knowledge, influence, and activity in which one or more systems are to be dealt with (e.g., are to be built). The term domain can be used to group mechanical and electronic systems. A vehicle domain describes the grouping of systems and functions in a vehicle that can be assigned to individual areas. Historically, there are 5 domains in automotive: Powertrain DomainPowertrain: is related to the system that participates in the longitudinal propulsion of the vehicle, including engine, transmission, and all subsidiary components.Click HereChassis DomainChassis: The chassis domain refers to the four wheels and their relative position and movement in this domain, the systems are mainly steering and braking.Click HereBody DomainBody Domain: includes the entities that do not belong to the vehicle dynamics, but to the car users such as Airbags, wipers, lighting, window lifter, air conditioning, seat equipment, etcClick HereHMI DomainHMI Domain: includes the equipment allowing information exchange between electronic systems and drivers (displays and switches).Click HereTelematic DomainTelematic Domain: is related to components allowing information exchange between the vehicle and the outside world (radio, navigation system, Internet access, payment).Click Here Previous slide Next slide From one domain to another, electronic systems often have very different features. For example, the powertrain and chassis domains both exhibit hard real-time constraints and a need for high computation power. The telematic domain presents requirements for high data throughput. However, the hardware architecture in the chassis domain is more widely distributed in the vehicle. From this standpoint, the technological solutions in each domain used are very different, for example, the communication networks, the design techniques, and the verification of the embedded software are different for each domain. These 5 domains, cover all the electronic/electrical sub-systems of the car. You can think of any sub-system that you can think of, and it will fall in one of the above domains specified. Let’s just deep dive into each of these domains to understand which electrical sub-systems come in which domain. Different types of functional domain in Automotive To understand each of the domains, we will broadly be going to answer 3 questions: What parts of the vehicle fall into the corresponding domain? Examples of Automotive sub-systems for that corresponding domain. Sensors/Actuators/Modules used in that corresponding domain. PowerTrain Domain: Parts of the vehicle fall into Powertrain domain Examples of Powertrain domain Parts of the vehicle fall into Powertrain domain This domain represents the system that controls the engine, such as: A) According to requests from the driver: → Speeding Up and Slowing Down as transmitted by the throttle position sensor or brake pedal. B) And from other parts of the embedded system such as: → Climate control (natural factors like air current temperature, oxygen level and environment annoyances such as exhaust pollution, noise and etc) and Electronic Stability Program (ESP):
The more realistic you get, the more distinct you become in modern world Gettobyte What is SHE (Security Hardware Extension) Technology? Secure Hardware Extension, short form SHE: is a standard that specifies performing basic cryptography ciphers and managing cryptography keys via automotive Microcontrollers. SHE has been stated as standard in automotive microcontrollers to protect the cryptographic keys from software attacks by hardening them into the memory of the microcontroller and to perform basic symmetric cryptographic ciphers like AES & CMAC for encrypting and decrypting the data. SHE standard is implemented in microcontrollers by having an on-chip extension(peripheral) as a security subsystem which follows, the SHE standard. SHE standard is stated by hersteller-initiative-software (HIS) consortium in April 2009. This consortium was founded in 2004 and consists of members from Audi, BMW, Daimler, Porsche, and Volkswagen to address activities and develop common automotive manufacturing standards. SHE standard states that the peripheral in the Microcontroller should have the following 3 blocks, to implement SHE standard in MCU: Control Logic: Connecting the parts of the CPU to the microcontroller. Storage Area: To keep the cryptographic keys and additional corresponding information. Cryptographic cipher core: a hardware core or module to perform necessary calculations for performing cryptographic ciphers. Automotive Chips, which have SHE peripheral: MPC5646C Freescale MCU’s S32K144 NXP Semiconductor’s MCU Components of SHE Technology SHE Technology Why SHE Technology? Working principal of SHE Technology? USE cases of SHE Technology? How to use SHE Technology? Add Your Heading Text Here
What is USB Technology USB is a technology which standardize the connection of peripherals to personal computers. It has largely replaced interfaces such as PS/2 connector (used for keyboard), ADB Connector (used for mouse), Parallel Ports (used for printers) and Game ports (used for video game consoles) which are used to connect different devices to computers. USB technology made it possible to connect all such different devices to computer via single port USB port. How Does USB does that: USB is a bus protocol in which our computer is USB MASTER and devices connected to it are termed as USB DEVICES. USB DEVICES Can be anything: keyboard, mouse, flash drives, hard disk, Audio Devices, Card Readers and all devices you can think of which are connected to USB. Now in USB protocol there is the concept of USB descriptor via whichUSB host that is computer can determine which USB device is connected and correspondingly detect which electronic device is it. The USB is specified to be an industry-standard extension to the PC architecture with a focus on PC peripherals that enable consumer and business applications. What is USB technology Architecture? USB hosts are also known as master devices, and they initiate all the communication that occurs over the USB bus. Typically, a computer or other controller is considered to be the master, only responding to other devices if requesting certain information. The peripheral device(USB Device), or the slave device, is connected to the host device, and is programmed to provide the host device with the information it needs to operate. Typically, peripheral devices include USB flash drives, computer mice and keyboards, cameras, and other such devices. There can be multiple USB devices but only one USB master would be there. The USB system uses the tiered star topology, in which 127 different USB slaves can be connected on the same USB bus. What Are USB Packets? The amount of data transmitted in USB is called ‘packet’. The data transfer that can occur within the USB protocol is discussed below. The data of the USB protocol is transmitted within packets LSB first. There are mainly four types of USB packets: Token packet Data packet Handshake packet Start of the Frame packet Data exchange between the host and device is known as USB transactions. One can think of USB transactions as complete data exchange that occurs between a host and device where all necessary packets are transmitted. Each USB transaction is composed of either 2 or 3 packets, depending on the transfer type being used. Each USB packet is designed from various fields like a Sync field, a Packet ID (PID) field, ADDR (Address) field, ENDP (Endpoint) field, CRC (cyclic redundancy check) field, and EOP (end of packet) field.  USB Packet Field Description Sync (8 or 32 bits): In USB protocol, every USB packet will begin with a SYNC field which is normally utilized to synchronize the transmitter & the receiver to transmit the data precisely. This field is long with 8 bits at high & low speed otherwise 32-bits long for maximum speed & it is utilized to synchronize the CLOCK of the transmitter & receiver. The final 2-bits will indicate wherever the PID field begins. PID(8 bits): The packer identifier field within the USB protocol is mainly used to recognize the packet type that is being transmitted. The length of this field is 8 bits long where the upper 4- bits recognize the kind of packet & lower 4- bits are the bitwise complement of the upper 4- bits. The resulting format of the PID(Packet identifier field) is shown below → → The PID Value: Indicates the type of packet/group( out of 4 one) and the format of the packet and the type of error detection applied to the packet. → PIDs are divided into four coding groups: token, data, handshake, and special, with the first two transmitted PID bits (PID<0:1>) indicating which group. Address field(7 bits): The address field of the USB protocol indicates which packet device is mainly designated for. The 7-bits length simply allows support of 127 devices. The ADDR field is specified for IN, SETUP, and OUT tokens and the PING and SPLIT special token. The address (ADDR) field specifies the address, that is either the source or destination of a data packet, depending on the value of the token PID. Endpoint Field(4 bits):An additional four-bit endpoint (ENDP) field, shown in Figure 8-3, permits more flexible addressing of functions in which more than one endpoint is required. The endpoint field is defined for IN, SETUP, and OUT tokens and the PING special token. Cyclic Redundancy Checks: Cyclic redundancy checks (CRCs) are used to protect all non-PID fields in token and data packets. In this context, these fields are considered to be protected fields.All CRCs are generated over their respective fields in the transmitter before bit stuffing is performed. Similarly, CRCs are decoded in the receiver after stuffed bits have been removed. Data Field: The data field may range from zero to 1,024 bytes and must be an integral number of bytes. Figure 8-4 shows the format for multiple bytes. Data packet size varies with the transfer type. Types of USB Packets 1. Token Packet: A token consists of a PID, specifying either IN, OUT, or SETUP packet type and ADDR and ENDP fields. The PING special token packet also has the same fields as a token packet. Token Packet is initiated by the host and determines if the host will send or receive data. For OUT and SETUP transactions, the address and endpoint fields uniquely identify the endpoint that will receive the subsequent Data packet. Setup – Used to begin control transfers. Out – Informs the USB device that the host wishes to send information. For IN transactions, these fields uniquely identify which endpoint should transmit a Data packet. For PING transactions, these fields uniquely identify which endpoint will respond with a handshake packet. An IN PID defines a Data transaction from a device to the host. OUT
In the new age of autonomous and connected vehicles, cyber-attacks in automotive are happening frequently. Discover in this blog, what technology is used to make our vehicles safe and secure.