feature article
Subscribe Now

Drive Safely

Many years ago I read a book about motor racing in which a secret team put together a car that went on to win the Le Mans 24-hour race.  The whole car was built from scratch, with a cast iron block drilled for cylinders, metal turned on a lathe for the wheels, and so on. This may, at a stretch, have been feasible for a one-off vehicle, but it was never an option once production line manufacture started. Henry Ford brought in components, even for the Model T, although the wonderful story that the packing cases in which the components were delivered were specified so that they could be dismantled and the planks used as floorboards may be an urban myth.

Today the car manufacturers — the Fords, BMWs and Nissans — are at the top of a complex supply chain. They are now assemblers of thousands of elements bought in from a range of suppliers.  Immediately below them is a group of specialist companies, usually called the tier one suppliers. These supply, amongst other components, the electronics systems that are central to, and a major part of the cost of, today’s cars. Supplying the tier ones is a chain of other companies including, amongst others, the semiconductor companies.

Until relatively recently, the OEMs — the car manufacturers — designed their cars and then gave a purchase order to the tier ones, possibly splitting an order between several suppliers. That is great for nuts and bolts and works moderately well for old-fashioned ignition systems or mechanical window-winding mechanisms. But when ICs began to find their place on the Bill of Materials, then life became more complex.

ICs, together with their related software, now represent a significant part of the cost of producing a new car. And, unlike the nuts and bolts, they are an integral part of what one can call the “personality” of a car – the electronics are what defines a car’s functionality. Where we used to play with carburettor settings and ignition timings to optimise the car’s performance, today all of this is determined by software running on silicon. Software on silicon also manages the drive train, braking, and suspension, and it provides a wide range of driver assistance tools, such as line following, distance information, even semi-automated parking. Then there is “infotainment,” the mix of GPS, traffic information, audio, and, for passengers, video. The list goes on and increases every year.

Given the central importance of silicon today, the straightforward supply model breaks down, particularly when entire systems can be replaced by a single chip. Silicon vendors have to be able to explain the potential of their products, not just to the tier ones, but also to the OEMs themselves.  All three have to work together to identify requirements and specify how they are to be met.

Until now, the different islands of applications have developed largely in isolation. A typical mid-range car today can have up to 20 or more Electronic Control Units (ECUs) – automotive jargon for microcontrollers and associated circuitry – with associated software, each dedicated to a specific function. Communication between these islands is through a range of different protocols, including CAN, LIN and MOST, often having to cope with disparate and, at times, incompatible interfaces. All of this complicates the design and implementation process.

Over the last few years, there has been a determined effort to simplify the situation, with the initiative coming from European automotive manufacturers and tier ones. The programme they instigated, called AUTOSAR (Automotive Open System Architecture), is a platform and methodological approach for creating integrated systems. Alongside this has been work on a communications protocol, FlexRay, and also work on automotive safety.

The core of the AUTOSAR is the AUTOSAR Run-Time Environment. Below this is the middleware; the RTOS, memory stack, communication stack, I/O stack, etc., running on a general purpose ECU. Above the RTE is one or more Software Components (SWCs), which are the implementation of the applications, and they communicate with the RTE through an AUTOSAR interface. Once an SWC is developed, it should run on any ECU through the RTE. Since multiple applications can run on an ECU, this opens the door to reducing the number of ECUs deployed – the dashboard management ECU could also run the SWCs for the interior lighting, for example. Each SWC running on the RTE is independent, so a problem with one SWC will not influence any of the others running on the same ECU.

Alongside the AUTOSAR architecture, FlexRay has been developed to create a robust and safe communication system between ECUs.

This leads us to the question of automotive safety. The domestic car is probably the most dangerous man-made object in the world. It is estimated that traffic accidents kill around 1.2 million people a year (that’s around two people every minute) and injure around 50 million a year (around two every second). And most sources suggest that these figures are underestimates. By contrast, airplane accidents kill around 1,000 people a year, on average.

While most of these accidents are caused by driver behaviour (alcohol still plays a significant part in many car accidents), there is concern over the safety aspects of all the electronics. Surprisingly, given all the legislative controls on cars, there was no automotive specific safety standard. This is changing, as many of the same group that is driving the work on AUTOSAR have also been involved in the work on ISO 26262, a safety standard specifically for automotive applications.

The core safety standard for all industries is IEC 61508 – Functional safety of electrical/electronic/programmable electronic safety-related systems. This is a multi-volume document covering all aspects of the product life-cycle, and it is based on the idea of Safety Integrity Level (SIL). A SIL is an indicator of the Probability of Failure on Demand (PFD), with SIL 1, the lowest safety level, or highest likelihood of PFD and SIL 4 the highest safety level, or least likelihood of PFD.

From 61508 has sprung a whole family of standards, such as IEC 61513 for Nuclear Power Stations, or EN 50129 for railways. What most of the derivative standards have in common is that they are designed for one-off projects (most nuclear power stations are custom built) or very low volumes. Cars are produced in high volume (although modern manufacturing methods mean that in mid- and upper-range cars, it is likely that no two cars are identical).

26262 is based on a development methodology, following the V method that is similar to that presumed for AUTOSAR. Using the approaches within the standard, it is possible to analyse the different elements of a system and determine the appropriate ASIL levels for each. Then, working with the standard, it is possible to create an appropriate development path, from specification through to testing. Systems developed within this standard should be demonstrably “safe”.

Even though it is still “under development,” ISO 26262 is gaining momentum. Tools are available for several stages of the life-cycle, from requirements analysis through to test. Semiconductor manufacturers are gearing up their silicon and software for the standard: Infineon for example, is building software and tools that make its TriCore processors a base for both AUTOSAR and 26262, communicating through FlexRay.

The work on FlexRay and AUTOSAR has been driven by the same companies, often by the same people within these companies. The core members of AUTOSAR and the founders of FlexRay both include BMW, Bosch, Continental, Daimler, Ford, GM, PSA, Toyota and VW. ISO committees are structured slightly differently in that their members represent the national standards boards of the different member countries, but when you look at contributors to 26262 committees within different countries, they include exactly the same people from exactly the same companies.

There are already cars with FlexRay, and both AUTOSAR and 26262, while not in their final form, are influencing the way developers are working. This integration of platform, communication, and safety standards is unusual, perhaps even unique (a word I use in its strictest sense). It is somehow satisfying that, at least at the superficial level, it is possible for organisations to work together to produce such a valuable result. 

Leave a Reply

featured blogs
Sep 26, 2021
https://youtu.be/Ivi2dTIcm9E Made at my garden gate (camera Carey Guo) Monday: Ten Lessons from Three Generations of Google TPUs Tuesday: At a Digital Crossroads Wednesday: Announcing Helium, Hybrid... [[ Click on the title to access the full blog on the Cadence Community si...
Sep 24, 2021
Wi-Fi, NB-IoT, Bluetooth, LoRaWAN... This webinar will help you to choose the appropriate connectivity protocol for your IoT application....
Sep 23, 2021
The GIRLS GO Engineering scholarship provides opportunities for women in tech and fosters diversity in STEM; see the winners of our 2021 engineering challenge! The post GIRLS GO Engineering! Empowers Our Next-Gen Women in Tech appeared first on From Silicon To Software....
Sep 23, 2021
The Global Environment Facility Small Grants Programme (GEF SGP), implemented by the United Nations Development Programme, is collaborating with the InnovateFPGA contest. Showcase your  skills with Intel Edge-Centric FPGAs and help develop technical solutions that reduce env...

featured video

Accurate Full-System Thermal 3D Analysis

Sponsored by Cadence Design Systems

Designing electronics for the data center challenges designers to minimize and dissipate heat. Electrothermal co-simulation requires system components to be accurately modeled and analyzed. Learn about a true 3D solution that offers full system scalability with 3D analysis accuracy for the entire chip, package, board, and enclosure.

Click here for more information about Celsius Thermal Solver

featured paper

Designing an Accurate, Multifunction Lithium-Ion Battery-Testing Solution

Sponsored by Texas Instruments

This paper highlights the benefits of a discrete solution over an integrated solution in order to meet current and future battery testing challenges. It also includes an example of a highly flexible battery testing design.

Click to read more

featured chalk talk

The Gateway to Connected Intelligent Vehicles

Sponsored by Mouser Electronics and NXP Semiconductors

Connectivity is going to play a vital role in the future of connected and autonomous vehicles. One of the keys to the success of our future automotive designs will be the incorporation of service-oriented gateways. In this episode of Chalk Talk, Amelia Dalton chats with Brian Carlson from NXP about the role that service-oriented gateways will play in the future of connected and autonomous vehicles and the details of NXP’s new S32G2 vehicle network processors that are going to make all of this possible.

Click here for more information about the NXP Semiconductors S32G2 Vehicle Network Processor