Karl Benz, a German inventor built an automobile in 1885, and patented in 1886. Though this was the world’s first production grade automobile, it was not until 1908, the very first car accessible to the masses when Ford Motor Company introduced the Model T. Since then, the automobile industry which has traditionally relied on advancements in mechanical engineering, has had a gradual transition to partly relying in electronics as well for new technologies. In the 1980s, technically advanced technologies in automobiles came into existence. In the present scenario, the number of Electronic Control Unit – the device which controls an electronic functionality, varies from 5 to 200, depending on the class of the automobile. To ensure a better-connected, safer, cleaner, smarter car, ECUs are playing an increasing critical role.
So much so, that the ECU market is expected to grow to $211 billion in 2030, rising at a compound annual growth rate (CAGR) of 5%.The rise in ECU usage casts a broader trend of increasing amount of electronics in every new generation of automobiles. The automotive electronics cost as a share of total car cost is expected to reach 50% from the present 35%. This trend can be attributed to rise of autonomous vehicles. As much as the technology in each new car is exciting, the safety and reliability of the electronics used is of paramount importance. As automobiles, cars in particular have become the primary mode of transport, it is all the more imperative to focus on safety of the technology used, as human lives are at stake. Naturally, consumers may be worried about the safety and reliability of the vehicles they may potentially be driving in future. This essay focuses on the practices, approaches and the ethics of engineers/developers working in the automotive industry to give a context about the happenings in the industry to the consumer.
Every major automotive companies are competing with each other to bring autonomous vehicles to the masses. However, working on a new technology without historical data or research puts automotive companies in an uncertain situation of naively manufacturing autonomous vehicle. Anyway, vehicles currently in production are generating enormous amount of data which manufacturers are exploiting to create better and reliable cars. Yet, managing and comprehending the data being generated is becoming an increasingly difficult task for companies. As more connected vehicles come to the fore, the automotive industry must analyse and understand the data being generated from these vehicles in order to create the autonomous vehicle with the highest quality of security, efficiency etc.
Electronics components in car can mean both hardware and software. As with any software, cyber security is a key concern in connected vehicles. A group of Chinese security researchers took remote control of a Tesla Model S from 12 miles away, tampering with the vehicle’s brakes, dashboard, door locks and numerous other electronic elements of the car. Although the hack was conducted in test conditions, it does throw bad light on the technology itself.
To take care of the software standards and oversee its implementation, a consortium of automotive manufacturers, suppliers was formed called the AUTOSAR. It is an acronym for Automotive Software Architecture. AUTOSAR is a set of standards which defines how software for automobiles maybe be developed. Following the AUTOSAR standard also has an advantage – standardization of Basic software, standardization of specification exchange formats leading to interoperability, software component re-usability leading to cost and effort savings, Layered architecture of Basic Software leading to more functionally precise implementations. There cannot be safety without security. Hence, AUTOSAR standard also provides a crypto module to encrypt and decrypt data flowing between modules within the AUTOSAR software stack.
AUTOSAR also makes use of the standard ISO 26262 for functional safety. ISO 26262 is an international standard for functional safety in the automotive industry. The standard applies to electrical and electronic systems consisting of hardware and software components in vehicles. ISO 26262 defines requirements to be met by the safety relevant functionality of the system as well as by processes, methods and tools which are used within the development process.
The ISO 26262 standard ensures that sufficient levels of safety are being met and maintained throughout the vehicle lifecycle. OEMs and suppliers using ISO 26262 to evaluate the safety of a vehicle’s electrical and electronic components provides multiple benefits – simplified access to global markets by ensuring compliance, avoid expensive vehicle recalls and brand reputation damages due to safety hazards, competitive advantage in interpreting and implementing the ISO 26262 requirements correctly. To give a few example, ISO 26262 based AUTOSAR software has the ability to request the detection and handling of safety issues like hardware faults at runtime, requirements on timing and logical order of execution of applications, communication protection of applications, data corruption, and wrong service calls. For complete ISO 26262 compliance, the hazards (safety risks) are required to be identified and assessed. Thereafter, these hazards are categorized based as per the Automotive Safety Integrity Level (ASIL) framework. These classifications are required to establish safety requirements and define acceptance levels of risks and ensure standard safety procedures have been duly followed.
If the software can be called as the brain of an ECU, the hardware is the heart. The hardware here in reference is the processors and other semiconductors which may be used in the ECU. There are different levels of autonomy ranging from 1 to 5, current vehicles are still at Level 3. While the ultimate aim is to reach Level 5 autonomy, there are a lot of challenges associated with it both in hardware and software.
To be completely autonomous in the context of hardware, first the vehicle has to have a functionality to sense and perceive data. Then the received data is to be processed using an algorithm which in all likelihood is an AI system. Then there has to be actuation to act on the processed data. The system is complex and broken with each segment having its own sets of challenges. Since autonomy is difficult both in perception and execution, conventional methods of testing semiconductors are just not enough. Companies have to take into account the environment and the actuation. It’s only then that they know if decisions being made by the AI are correct in the context of the whole vehicle and getting the right operation. All this has to be done while considering the ASIL (Automotive Safety Integrity Level).
The semiconductors are also expected to be cyber security compatible. Above all this is the aspect of performance of the chip. This is measured in performance per watt and TOPS (Terra Operations per Second). To develop a miniature chip, which should have a superior performance and withstand harsh environmental conditions is a herculean task. Another less talked about issue is the development time required for these technologies. Tape-out time is defines as the final phase of a design life cycle of a product before the production of the product starts. The average tape-out time of a car is 3.5-4 years. Whereas, it is around a year for a silicon chip. These timelines have to be synchronised perfectly for a reliable development because if the usage of an automobile is clear, the silicon chips can be developed accordingly. The design of hardware is also affected by the complexities in software. A glaring example of this is the AI system. Typically, AI systems are trained with data sets. So, an AI training model which may work in one region may not be work in another. But all these models combined together have to work together on a chip developed for global usage. There is more importance placed on hardware software co-design. Traceability of a chip is another important factor, because the average lifetime of a car is more than 10 years. If a bug is detected newly, it has to be traceable to its origin.
When it comes to software that is mostly dominated by AI systems in fully autonomous vehicles, new set of challenges arise. Since AI rely on data, data-related issues are more. In fact, it is often said that an AI system is only as good as the data it is being given. AI systems require large training data sets to identify patterns. These data sets have to be good in terms of quality and quantity. These data sets have to be labelled as they are trained in a supervised manner. There are many different approaches of labelling data, though not all of them are suitable for autonomous vehicles. Then there is the issue of explanation. If an AI system has taken a decision, it is to be known how the AI took that particular decision of all available choices. Since while training, data is fed to the AI system by humans, there is a chance that biased data is fed by humans leading to undesirable consequences. Bias can also occur in many other ways, starting with how data is collected to how it is probed.
A nearly error free AI model has to be integrated with other parts of the automotive system, which may have hard coded rules, whereas AI system takes dynamic contextual decisions. It becomes all the more challenging when considering different parts of the system are supplied from different vendors.
Security and reliability are not the only obvious issue the manufacturers are facing. Autonomous cars cannot be made mainstream until the technology can assess its surroundings in real-time and make ethical decisions. Case in point is the “The Trolley Problem” – You are standing by a railway line and you spot a runaway train. You look down the tracks and can see five workmen standing on the rails who have not seen the train. They are too far away to hear you and are not looking in your direction so you can’t signal them. You then notice you are standing beside a lever which controls the tracks. If you pull the lever the train will be diverted down a side track. But on the side track you can see a single worker who again hasn’t seen the train and is too far away to warn. What do you do? If you do nothing the five workmen die. If you pull the lever the single workman dies but the other five survive. It is an ethical dilemma. Should the car always prioritise its owner’s safety even if that means ploughing into a crowd of pedestrians? Should the car try to calculate the probable death tolls and base its decisions on that? Should the car prioritise the safety of children over the elderly? Mercedes has reiterated that the software in its autonomous vehicles will protect the occupants of the car above all others. Ethical decision making in an autonomous vehicle is a true Pandora’s Box.
Currently, there is no international and mutually agreed standards between the software and hardware stakeholders involved in the development of autonomous technologies. OEMs and technology giants operating in the automotive market must find a solution to the technological, security and ethical issues autonomy poses. At the moment, it seems that the software engineers who program the AI system make the decisions. All things considered, the technology that goes into the making of autonomous vehicles is truly exciting. I believe OEMs are to be made answerable to how their car behaves and responds. The governments have to proactively frame regulations for the industry. Suppose there could be an international legislation to define AI ethics. All of these measures coupled with an acceptable standard covering all aspects of autonomous vehicle technology will give a re-assurance on the safety and reliability of an autonomous car