Automotive software developers do not discriminate – they typically develop software for cars with internal combustion engines,  electric motors, or a combination of both. In fact, apart from the engine control unit and the battery charging and management system, most ECUs are identical and there have been many of them. Why do we say “have been”? Because in addition to the disruption of the electric powertrain that has been widely reported in the media, there is also a parallel “aggregation and connectivity revolution” underway. And this hidden revolution is much more complex than the powertrains one – which may be one reason why the media are not talking about it.

Tesla also started this disruption by developing a car with mainly 14 ECUs. This car is updateable remotely, while traditional automotive competitors put up to 100 ECUs in their models, which must be updated in the garage. Fewer ECUs also mean lower production costs, but this requires significantly more software expertise to reconcile more functionality on fewer processors and functional safety with cybersecurity.

One approach for developing more centralized software applications involves continuous integration and delivery (CI/CD). That also means continuous testing, documentation, and certification – but in the automotive sector, this is a much harder game than in other industries. Compared to consumer or enterprise software, one must regard strong functional safety (FuSa) standards and at the same time cybersecurity standards in combination when developing solutions for the automotive sector. While expert knowledge is available for them, such a combination is totally new. Common best practices that work for FuSa sometimes crash with ones for cybersecurity. In short: FuSa best practice strives to develop based on classical ‘waterfall’ processes of hardware products (a product that underwent only the slightest changes once it was in the field), while today’s cybersecurity level will be maintained through continuous updates.

In addition, many reliable FuSa functions must be re-used. However, these may come from up to 100 different ECU development teams. Thus, an attempt is made to separate these functions from each other so that they can be maintained independently. This is usually done with hardware-supported hypervisors.

To support these new challenges software architects and integrators need a reliable, pre-certified base for their application.

Based on its own automotive OEM customer requests, eSOL developed the modern eMCOS RTOS platform, based on the new multikernel technology, which is optimized for modern multi/manycore SoCs that are used for future high-performance computing ECUs. This comes with a hypervisor option and an IDE that successfully addresses the new CI/CD pipeline development style.

Michael Grabowski,
Senior Product Marketing Manager

About Michael: Michael has been working in the field of embedded applications for 25 years. He started as a Product Development Engineer for gas sensors in explosives hazardous areas across multiple industries, and then moved to the area of chip manufacturing of 32-bit MCUs as a system engineer. Finally, he was responsible for 64-bit multicore SoCs for automotive as a Product Manager. Since April 2020 Michael has served as Product Marketing Manager for embedded software products at eSOL, especially in the area of real-time operating systems for 64-bit multicore SoCs for automotive and industrial applications.