Auto-coding versus hand-coding of automotive embedded software
- Sept. 4, 2015
- Marcel Romijn
A consistent trend in the automotive world is to have less and less hand-coded software. Especially those areas that change rapidly such as the control systems and vehicle features. We asked BRACE Automotive Engineer Steven Bouwmeister for more details.
What is your position at BRACE Automotive and how long have you been working in Automotive Engineering?
Steven: “I am a Project Engineer specialized in Model Based Design and have been working in the automotive business for about 9 years. Most of this time I’ve been involved in developing software for the engine management system related to optimizing the drive ability and fuel consumption”
What is the main reason on why hand-coding is abandoned? Is it cost price, resource capacity, something else?
Steven: “Most automotive companies are still using to some degree hand-coded software since that has been proven to work and is established in the company. And there is still a lot of legacy. The flat programming process is specialist work and is mostly outsourced. Therefore software requirements need to be specific and very clear to get what was intended.
If you compare hand coding with automated generated software code, the hand coded increases the risk of fault intrusion and is very time-consuming. Testing of the software created by hand is also more difficult if you compare this with an automated process, where test-cases can be re-used and can also be generated.
However; moving towards an automated software code generation process requires a mature architecture and modelling rules that takes phased introduction (change of way of working) and validation (compare to old/hand-coded process) to establish.’’
Wouldn’t auto-generated software code be less efficient in terms of processor or memory usage?
Steven: “For rapid control prototyping (testing of the first concept ideas on a vehicle) the way the software looks like and how much memory is used is not very important. For production code this is important since e.g. a memory overflow, missing of calculations or unnecessary calculations could cause the software to behave not as intended or even crash. The software architects will guide this by defining the interfaces, timing schedules and memory allocations for all software functions. Also the memory capacity and processor calculations need to be taken into account when defining the software. A big element here is that automated code often exists of very small blocks of reusable code (optimized by software engineers) that are put together. I also believe that for the really critical control units a code review remains needed, even with an automated software generation process since the tools/scripts which create the automated code don’t know all the choices/ restrictions given by the software definition engineers”
Which areas remain hand-coded still, and why?
Steven: “In general for embedded systems the basic software like I/O drivers, memory hardware abstraction and communication drivers remain hand-coded. These are hardware/platform dependent and require specific adaption. This coding is usually performed by the suppliers of the hardware platform (ECU), where the application software is more and more automated by code generation.”
What are the capabilities of BRACE in this field?
Steven: “The Model Based Design & Auto-coding cluster has several engineers with some specializing in the lower parts of the software development cycle (V-cycle). Regarding software development BRACE has engineers working in the field of software requirements definition, software architecture and configuration definition, software creation with automated code generation and testing of the software up till vehicle integration."