Automotive Software Panel

October 23, 2012, Renesas DevCon, Anahiem, CA—A panel moderated by Martin Baker considered the challenges of developing new categories of automotive products. Panel members were: Peter Aboud form Altia, Ken Batts from Toyota, Scott Chemello from Bosch, Mike Grimes from GM, John Mills from SimuQuest, Thierry Rolina from Elektrokit, and Ian Wright from WrightSpeed.

Baker mentioned that most of the new categories are software dominated. They are comprised of 10-100 M lines of code and provide new features and capabilities to existing devices. The issues are lead time and software quality. Systems integration is a major problem since the new code might be from multiple software sources and will have to interface with 50-100 controls. The safety and standards compliance are difficult for the entire system, and the multitude of off-board communications means that module interactions can be highly disruptive. As a result, software in now the bottleneck for new developments.

Aboud commented that creation and integration of all the vendors is challenging.
Rolina added that the software is challenged to bring the functions to the product.
Batts appended that the industry is moving to a system of systems, so it is very difficult to isolate anything in a car.
Chemello noted that the costs are moving from hardware to software.

Hardware changing to software and electronics?
Grimes noted that in the old times, the ’80’s, things were hard. Now things are getting better.
Wright stated that his background in network efforts and big systems was much harder than cars. Software is not so hard if you are experienced.
Mills added that software complexity is increasing, so the tool complexity and interoperability are becoming more important.

Changes in methodologies and tools?
Batts suggested a strategy to move to model-based design and development. Reuse IP and create plant models.
Rolina stated that the EU has many useful standards for autos. These changes are getting into the supply chain, so design should stay generic as long as possible to take advantage of the new supply systems.
Aboud observed that there is a lack of experience at the engineering level. Fear and inertial form barriers to change and improvement. The users want a cheap tool chain rather than spend money for good tools. Tool use is uneven since many engineers don’t know how to use them.

Tool integration moving to a full development environment?
Chemello mentioned that the 15k requirements need tracking. Companies need communications across departments and need to work from a single executable specification.
Rolina stated that 10-20 people work on tool maintenance.
Mills concatenated the existing processes are not designed for automation.
Aboud pointed out that interoperability, or the lack of it, is also part of the business model for the point tool makers. The costs of interoperability are similar to those for traceability, there is no ROI for the efforts, but it is not a technical problem.

Autosar role?
Rolina offered the availability of building blocks and a suite of dependent modules are available. The time to adopt the tool is dropping with time and experience
Mills differed that this is just a sales pitch. There are some success, but a lot of frustration and issues with standards.
Chemello added that throughput is poor.

Autosar evolution a concern?
Mills mentioned that this is a model-based versus traditional software issue. The autosar overlay is complex.
Grimes advised that it is not close to its promises, but it works. Standards are evolving, but there are many open issues. For example, they now have a CAN stack, but cannot address complex I/O.
Rolina defended the concept of plug-and-play software that is hardware agnostic. It offers high reuse and “easy” maintenance. This issue is about configurations versus parameterized blocks for development.
Wright submitted cars are like the network world with its 7 ISO layers. External communications are through standards, but internal communications are unique.

Resource shortages and how to fill the resource gap?
Aboud submitted that this is head and not a body experience. New people need mentors to lead and offer suggestions. Employee retention is the key. Retention leads to an enlarged experience base and higher domain expertise.
Batts noted that the Center for Automobile Research considers resources to be a critical shortage in engineering talent that has to go to the educational system for help. The University of Pennsylvania now offers an MS program in embedded systems to try to address the needs. Other consortia are working on getting more embedded systems engineers.
Aboud cautioned that this shortage is geographic-specific. We have no software pipeline people, so software development gets outsourced to India and China. In the US, we also have an age issue for experience and change.
Grimes stated that new hires require lots of training because the schools are not teaching appropriate subjects. It’s a training issue. Some tasks have to be outsourced while others stay in house. For example, power train software needs someone with driving experience.
Mills observed that people are not matched to the tasks of value. The legacy processes, flows, and tools block change.

Organizational roles and key players?
Chemello responded that significant change is happening in the industry. The old tier 1 module is now a box and low level drivers coming from the tier 2 suppliers. The tier 1 suppliers are now generating middleware.
Rolina explained that Chrysler started in ’00 and outsourced systems and software. They moved some of the integration tasks down to the suppliers.
Grimes complained that there are many changes in the industry. They now expect drivers and MCAL to come with the microprocessors. ASICs need controllers, drivers, and some type of SDK from their single source suppliers. Because the software comes from multiple sources, their tier 1 suppliers need to do the hared parts of the integration.
Rolina offered fit the function into a box and run. The changing industry is moving towards a software tier 1.
Batts noted that in the past, the tier 1 suppliers developed the power train software. Now the software development is back in house because the application development has to integrate with the function.
Mills offered a model-based solution is evolving. The challenge is to manage the data in a geographically distributed environment. The tools need to calibrate the variables to address the complexities and visualizations, and understand the functions.

Value and need of validation?
Mills agreed that this is important. Developers need to develop for defect-free designs. Then they have to validate that the design does what it was designed for, and evolve the design on the test set.
Batts noted that they spend half of their time on validation and verification.

Is there a place for PC, C++ and cross platform development, standards for code?
Batts answered the ecosystem for software-defined models and integration tools exists. The semiconductor manufacturers are supplying some of the software and support along with their processors.
Rolina added it’s fairly simple to move code into the target, with ISA and bus-defined models. The tool environments can start with a high-level application and move it to a target processor. This environment allows the software development to start earlier in the design cycle.

Hardware, ARM in the cars?
Grimes answered no, because the core for the functions is unknown at the start of a project and the peripherals can change during development. The tools don’t care, but the chips matter. The biggest issues are safety and security.
Aboud disagreed. There are lots of ARM processors in cars. By starting with abstract software to minimize any hardware dependencies, the design can use any processor. The big design issue is how to connect to the peripherals. The AMBA bus requires some specialization, but is ok for graphics and existing stacks.

Model-based versus Autosar, will they co-exist?
Rolina posited that the choice is client dependent. The future challenge is how to prove bits and pieces on a single target. With hypervisors and other architectures, the solutions still need to meet standards requirements. Users have to determine what is critical and if a given processor has sufficient headroom for the app.
Aboud wondered if the end OEM will benefit. Commonality and interchangeable code weight versus a general solution.
Mills offered the virtual development capabilities before hardware is available, and platform independence is important. Users can always configure after evaluation.
Batts suggested moving to multicore processors to address performance issues.