BLOG: Five layers to systemize when working with constantly growing embedded software
Starting as a software developer straight out of university, the sheer size of the code base for an electronic control unit (ECU) in a vehicle was overwhelming. We are talking about 4000+ files! And that is not including all the additional overhead for compiling, testing, documentation etc. Luckily, colleagues before me saw the same problem and figured out a solution to make sense of it all.
In this blog post I will highlight some key considerations and limitations when working in safety critical embedded systems with real-time performance requirements. In slightly less technical terms – an electric system in a vehicle.
Where everything starts
Embedded systems in general have a few limitations to consider. Performance is in the order of 1% of the phone you have in your pocket, persistent and volatile memory is limited (typically ~500 kB), and real-time performance is of the highest importance. These aspects combined with other factors result in C being the suitable language and in abstraction becoming necessary to not take ever-changing hardware into account. This is also where the systematization starts – the first layer of the embedded software is basically a hardware abstraction layer. Some would call it an operating system. The purpose is to do as little as possible since this layer needs to adapt to the hardware that it runs on. You need to consider different CPU generations, memory sizes, number of inputs and outputs (analogue, digital, PWM, LIN, CAN etc.) but also factors like calibration protocols (CCP).
The generic essentials
Next up in the hierarchy of software is the middleware. Many essential, but generic, functorialities are found here. Configurations are handled together with utility functions like PID controlling, filtering etc. Moreover, the middleware makes sure that data is stored in flash memory (persistent memory) when needed. Lastly, the real time signal database is also a part of this layer.
My home turf
We have now come to the layer that I am most familiar with: Low level application! This layer makes sure that the next layer gets signals in and out in the right frequency, with correct scaling and on the right channel. It could be a request upwards in the system hierarchy to another ECU over CAN, a LIN message to a simple component downwards or receiving analogue inputs from a temperature sensor on a pin. All this data should be stored on a suitable sized data type, perhaps an 8 byte integer or 32 byte float.
When something goes wrong
So what happens if a physical sensor goes bad? Let’s take a temperature sensor in a battery pack as an example. Well then this layer, the sensor layer, has got you covered! This piece of software makes sure that a secondary sensor is used, perhaps located in another part of the pack. If that is not an option, a potential estimation based on some other data could be good enough. This is also the layer were filtering of signals is done as well as pure virtual sensors.
The layer that makes the difference
Last, but by far not least as it is the largest part of the software, is the application layer. This layer is usually developed with support of model based design tools, Simulink or similar. This is the part of the software which is unique to each project and ECU. Depending on the use case, the application could consist of logic to make sure an internal engine runs as it should, a battery pack that needs monitoring or a cab climate system that makes sure that the temperature is maintained at a chosen level.
Is everything done in C?
While all these layers are being developed, a huge off board (everything that is not “on” the vehicle) team is working with everything from fleet management and analytic systems, CI/CD pipelines, automated SIL and HIL environments, frameworks and standards for code safety and efficiency. The list can go on and on! It is safe to say that if you enjoy working in a software environment – there is a place for you at Scania!
Glossary
ECU – Electronic control unit
PWM – Pulse width modulation
LIN – Local interconnect network
CAN – Controller area network
CCP – CAN calibration protocol
PID – proportional–integral–derivative
CI/CD – Continues integration / continuous delivery
SIL – Software-in-the-loop
HIL – Hardware-in-the-loop
By Niklas Timarson
