Insights
New breakthroughs in AI, machine learning, and automation have generated so much interest in the business sector and the media over the last five years that these three distinct fields now tend to become conflated in the public mind — particularly when any of them fail.
Perhaps that’s inevitable since there’s some conceptual crossover between systems that attempt to imitate human thought processes, systems that imitate human learning processes, and systems that replace repetitive human activity; but it can also mean that little distinction is made in the public mind between the safety standards and programming practices behind such varied fields as infotainment, business systems, and safety-critical embedded software systems.
In reality, there’s a world of difference. NASA long ago set the tone and philosophy for safety-critical vehicle software, favoring proven languages over less seasoned newcomers, and prioritizing the ‘human factor’ of acknowledged expertise in embedded software development. It’s a mindset that has trickled down to the industry development pipeline for safety-critical consumer-level systems, for very pragmatic reasons.
To illustrate this, we recently invited one of our leading embedded software developers to outline the level of professionalism and individual attention necessary to create such safety-critical embedded software solutions for ADAS (Advanced Driver Assistance System), one of the key fields in which Tremend is a market leader. This fascinating series of posts looks at the rise of the C programming language as the predominant programming space for safety-critical code from the early 1970s through to the present time.
A ‘traditional’ approach
The more frameworks, interpreters, and virtualization factors code has to pass through, the more the opportunity for unwanted outcomes can multiply. If you’re developing a trading algorithm, that’s unfortunate; if you’re developing vehicle systems, it’s potentially fatal.
Therefore the embedded development sphere is startlingly frugal and circumspect in comparison to almost any other and remains dominated by the venerable C programming language, and various industry-specific subsets of it (such as MISRA C).
C has retained its crown in embedded software for nearly half a century, not in spite of the fact, but rather because it offers complete power to the programmer, and places the onus of due care and liability on the software producer. It’s, therefore, a Spartan, high-vigilance pursuit.
In such a sensitive sector there are still — naturally — filters and check-points for possible program anomalies, such as ‘qualified’ compilers which assemble the code with an eye to possible issues; industry-specific subsets of C which are often imposed on developers at a regulatory level, along with strict guidelines for how they’ll be used; and static analyzers, which can run through the theoretical execution of code, looking for unintended and unwanted outcomes.
However, none of these methodologies, individually or in combination, can compare to the potential of an experienced programmer to recognize a whole slew of factors that can affect the reliability of a safety-critical system.
A bespoke approach
There’s little room for a homogeneous or overly-systematized approach to embedded software development in safety-critical systems such as ADAS. The programmer’s foresight works with the pipeline tools – including static analyzers, qualified compilers, and the restrictions of a language subset (such as MISRA) – to ensure that no unintended consequences occur in the entirety of the possible environment variables in which the software is intended to run. It’s a resource-intensive approach that’s impractical for most software/hardware development arcs, but essential for the embedded sector.
It’s a pity that the media rarely reflects the sheer skill and number of man-hours that go into their creation, nor acknowledges the influence of the stringent quality-control frameworks which have built up around the sector in the last thirty years.
We invite you to take a more detailed look at the embedded programmer’s decades-long hunt for software integrity here — it’s all a far cry from the ‘point-and-click’ culture which is too often depicted around the subjects of automation and AI in the automotive sector.
Leading car manufacturers all over the world (including Japan, Germany, and France) depend on Tremend for Human Machine Interface (HMI), Advanced Driver Assistance Systems (ADAS), and Highly/Fully Automated Driving (HAD and FAD) solutions.
