Software defines the most advanced features of current and upcoming vehicles, from infotainment and connectivity to advanced driver-assistance systems and autonomous driving. As more consumers expect those features to be up to date — much like apps on their smartphones — OEMs and their partners need the freedom to meet those expectations through over-the-air (OTA) updates that extend throughout a vehicle’s life.
Decoupling software from hardware provides that freedom.
Importantly, it also enables OEMs to meet global, regional and national requirements to use aftersales software updates to keep vehicles compliant with the latest regulations governing ADAS, automated driving and other functions.
The traditional approach
Historically, automotive companies developed software to run on specific, specialized electronic control units (ECUs). A premium vehicle contains more than a hundred such ECUs, connected by a huge spiderweb of cables for the power and automotive bus systems. The cables are bundled into thick and heavy cable harnesses, which usually have to be assembled by hand. During production, a harness then has to be placed manually into a vehicle body and manually connected to all of those ECUs through the vehicle. It is nearly impossible to change anything after the vehicle is sold.
Software architecture has not been treated much differently. Each ECU contains features for which the software interfaces are defined at a network protocol level for CAN, LIN, FlexRay and Ethernet. This definition also includes time constraints, such as cycle times. When a vehicle and all of is components are validated, they are considered final – and they are not expected to be touched again except for regular service.
The development process worked sequentially. First came the product definition and requirements phase, which started at least five years before the start of production — followed by hardware design, software design, a request for information, a request for quotation, a sampling phase and a bidding phase. Then the integration and test phase would start, concluding with vehicle validation and ramp-up of production. Each phase of development had to be completed before the next could begin.
Even though OEMs created toolbox systems for car lines – which helped developers reuse mechanical components and ECUs for new car lines – it still took a lot of work to integrate those ECUs with new ones. If the hardware changed, developers had to build all-new software for each new hardware platform because they were unable to efficiently reuse code between those platforms. Once set, requirements were rigid, and incremental development cycles presented few opportunities to revise and test code. Integration of a high number of different ECUs together in a vehicle contributed to complex testing and validation processes and made it very difficult to address bug fixes when the vehicle was in the field.
The decoupling advantage
In a decoupled architecture, hardware and software are free to evolve on their own independent development timelines and update cycles. In addition, different software modules are decoupled from each other using various technologies, creating what we call “freedom from interference” between software modules. The separation minimizes the impact of software changes and, where possible, obviates the need for revalidation of an entire vehicle when changes are made. With decoupling in place, software modules can receive updates more easily over the life of the vehicle — and can run on different hardware platforms.
Learn more about the benefits in our white paper.
