Software development poses unfamiliar challenges to automotive value chain
Over the past decade, software complexity in cars has increased in a breathtaking manner. In automotive projects, developers today have to deal with 15.000 to 60.000 requirements (Doors items). The volume of a typical project is 500.000 to 3 million lines of code, and the work has to be coordinated among 100 to 250 developers, explained Karl Fuchs who oversees quality management for Infotainment and Connectivity for automotive supplier Continental AG, in his keynote speech. To make things even more complicated, the time to market does not grow in lockstep with the requirements – quite in the contrary, it is declining.
One possible way out of the dilemma is the reuse of software. However, in some cases, the use of cost-optimized hardware poses limits to software reuse. In order to maintain control of design complexity, Continental suggests making as much use of modeling as possible. "Software developers should transform requirements in use cases – and users should extensively use modeling techniques", Fuchs said. This helps designers go get a top-down vision of the problem to be solved instead of digging into details and lose track of the big picture. Fuchs compared the situation of an automotive software developer to VLSI chip design. "No chip designer needs to exactly understand the way millions of transistors interact in such a chip. Instead, chip designers rely on RTL level abstractions. Similarly, no software developer can keep track of the interaction of thousands of C++ classes. "Examples show that modeling techniques make it possible to generate code with significantly less program errors", he said, adding that the code generated by modeling is also much more compact than by conventional methods.
Christian Salzmann, responsible for software development for body and driver assistant systems at BMW, shared Fuchs’ assessment that there is potential to improve the software design process. BMWs vision towards this end leads through a reduction of the hardware complexity. The carmaker’s E/E architects are working on ways to transform functions from hardware to software which runs on fewer but more powerful microprocessors within the vehicle. Ultimately, each domain in the car – body, chassis, powertrain and infotainment will have one central CPU which runs all the software associated to this respective domain.
BMWs strategy also attacks the complexity at another point: The company intends to do away with automotive-specific, proprietary technologies and build on standard technologies instead. An example is the internal data network in the car where BMW bets to a high extend on Ethernet instead of proprietary protocols. By 2015, BMW plans a comprehensive deployment of Ethernet in the driver assistant system domain. "Over the years, we gathered experience with CAN, FlexRay, MOST and Ethernet. Ethernet was the networking technology with the least problems" Salzmann said.
Despite the retarding moments described by Continental’s Fuchs, OEMs have a huge interest in the reuse of software code, Salzmann confirmed. "This helps us to reduce time to market and improve the flexibility as well as the quality of the software," he said. "We have to be able to get our design projects done within 15 months – and this can only be done with software reuse".
In order to reduce design cycle time and speed time to market, three preconditions are necessary: The availability of standard platforms; software competency in the hand of OEMs; and new types of collaboration. Autosar, the automotive standard software framework, has already had a positive impact. "Autosar brought us a giant step forward", the BMW software expert said. Besides Autosar, the carmaker also relies on the Genivi infotainment platform as a pillar of its software strategy – not a big surprise, as BMW was one of the founding members of the Genivi alliance. The carmaker regards Genivi not only as an infotainment platform, but intends to use it also as the environment of choice for driver assistance systems – in particular for systems which make use of image processing. "For such applications, Autosar currently does not offer any support. Currently the most promising platform is Genivi", Salzmann said.
Automotive OEMs should also build up or expand their in-house software expertise for cars, Salzmann said. "Domain engineering is a core competency; it can only be done by the OEM – and for this reason, OEMs have to participate in the software architecture design", he affirmed. At the same time, the expert advocated a change in the way software is developed: Classical automotive engineering processes – such as the widespread V model – do not scale for software, he argued. BMW already gained positive experiences with iterative approaches similar to what is known as the "agile" development strategy. "After all, the Eclipse development platform has also been written using this approach", he added.
New forms of cooperation between the members of the automotive value chain, in particular between OEMs and tier ones, are becoming necessary not only for strategic reasons, but also for technical ones: The OEMs have the task to integrate software pieces developed from various third parties. If runnables from multiple vendors concurrently run on the same real-time platform, the system can run into timing or jitter problems. Since Autosar rules are not sufficient to describe the requirements to avoid these effects, the development partners have to find alternatives."As long as standards do not support in full the possibility to describe these effects – and I believe that it can take a long time until they do so – one will need to rely on specialist partners such as Inchron for the software integration," Salzmann said.
As an ad-hoc solution to the problem, the BMW software expert suggested a process he described as continuous integration. The main feature is that all developers involved in a project should work against the same code basis. In order to enable software workers to do so, a common repository is required.
There is another factor that affects the complexity of the process. It has to deal with the attitude among software developers. Software workers should learn from chip developers, Continental’s Fuchs suggests. "A VLSI chip designer knows that he has no more than maximum two chances to get the design done on time. Software developers use to think they can change their product anytime – even in the field, if needed." This attitude, Fuchs said, should change. If first-time-right thinking would be established in software developer’s approach, complexity could be reduced inherently.
To mention just a few other presentations, Ralph Mader from Continental provided insight into the complexity of engine control units. He went on to lecture about various strategies to take advantage of multicore controllers for combustion engines. Florian Huber of Sensor Technik Wiedemann described by means of practical examples how to test and optimize the safety-critical battery charging process during real-time simulation.
Stefan Hohrein and H J Elsaesser engaged in a dialogue about how Continental integrated three functions in a new Autosar-based controller – and managed to estimate and optimize the required maximum computing performance even before the implementation phase.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
