In the automotive software development bubble, Software Defined Vehicle architecture seems to be perceived mainly as a change in the EE architecture. From traditionally distributed architecture, with tens of smaller or bigger ECUs, that communicate with each other using various vehicle networks like CAN, FlexRay, Ethernet, SDV presents a shift towards the architecture with a single powerful central computing unit surrounded by relatively simple ECUs acting merely as interfaces for sensors and actuators. Of course with that change, software also has to be designed differently, but it's the EE aspect that get the most attention.
Maybe this is the case because OEMs and Tier-1 suppliers are traditionally dominated by electrical engineers and software has always been an addition to the hardware for them. But to me, it's been always the other way around - hardware was only the platform to run the software on. So when I think about SDV I think about changes in the software design approach, in the first place.
Developing software for cars, lately, wasn't a pleasant or easy task. Mainly because the software frameworks and processes required to ensure quality, created 20+ years ago, have never evolved enough to match the needs of growing processing power, complexity and demand for advanced features like ADAS or infotainment systems. As a result, software development became costly, with tons of bugs and months of testing to fix them all before start of production. So the end product, even though expensive, was never very impressive. Did you ever wonder why your 300 EUR smartphone works faster and has more features than the central screen in the car that costs 30-40k EUR ?
I may be biased, but what interests me in the whole SDV movement is the chance for the automotive industry to fix the tedious and inefficient software development process. Diagram below shows oversimplified architecture, typically seen in current SDV designs. It includes legacy ECUs. This components are usually running some sort of safe RTOS, they may control something as simple as wipers or windows or more complex things like radars or ultrasonic sensors. Software of these components is developed in "traditional" way, using waterfall development model. Due to relatively low complexity and high criticality of functions performed by some of these components, this way of development is appropriate and not so much of a problem. HPC (high performance computer) is the central unit, running all advanced algorithms like ADAS, instruments cluster, infotainment etc.. Zone controllers are the bridges that terminate the signal-oriented buses like CAN, and providing packet based interface (usually ethernet) for the HPC.
With such electrical design as a foundation, Software Defined Vehicle architecture brings few important concepts that may allow to apply modern, flexible software engineering techniques.
One of them is hardware abstraction and standardization. It may be obvious, specially for Linux developers, that hardware should be abstracted from the software and device driver interfaces standardized so that the software that uses them can be hardware independent. Organizations like COVESA or wider SDV Alliance are working on creating standards and frameworks and guidelines to make interfaces that will allow interchangeability between vendors. Initiative called VSS (Vehicle Signal Specification) aims to normalize catalog of signals used across vehicle networks. It should allow creating hardware abstraction layers that are vendor-independent.
Another concept brought by SDV is conversion of signal-based interfaces into service based APIs. This will enable decoupling the software components that implement high-level features from the underlying architecture of ECUs and communication between them. For example, application that needs to turn on cabin lights, doesn't need to know exactly the topology of lighting controllers in given vehicle and signals that need to be used in order to control the lights. These details shall be hidden below the service-oriented API, exposing only functions that can be used by the application or a microservice regardless of the vehicle they are installed in. This concept may be obvious for software engineers from outside of automotive industry, but believe me, this is something "revolutionary" in car's software.
Automotive software already uses virtualization on a large scale. Mainly for bad reasons, if you asked me. They use it because they like buying software from many suppliers, ignoring the fact that it results in running 3 different operating systems on one chip. SDV aims to put some more thought and normalization in it but also introduces wide use of containerization technologies. Containers are used to isolate software components from each other and from the underlying system. This powerful concept allows to achieve Functional Safety goals (freedom from interference) as well as encapsulate development of high level software components.
With all these powerful concepts, system designers can split the system in to the domains of high criticality and safety requirements and separate them form non safety critical parts. While safety critical portion of the system have to be developed using the old and slow development model, the non-critical parts can be now developed in a modern way known from SaaS and mobile apps. ADAS algorithms or instruments display can be developed using heavy, waterfall-based development model that allows to achieve high level of safety. On the other hand, components like music player, and other non-critical UIs can be developed in a light-weight model, with no or little access to the target hardware, benefitting from service-oriented APIs, continuos integration, microservice architecture and allowing to produce feature rich components that can be installed and updated over the air.
Now it's up to the designers to draw the division line, enclosing the critical/slow development in the possibly small perimeter, also making these components standardized and reusable so that they can be developed once and reused in many projects. Because ultimately the goal of SDV is to make the car a "computer on wheels", where software can be developed in a safe and productive environment.
Comentarios