Software Think Science, not Art
Software development is popularly seen as an individual pursuit of trial and error. But that is far from true on any substantial programming project, where a large team of developers are working on complex systems.
The discipline of software engineering is a science rather than an art. The principles of repeatable, process-driven development for creating robust, high-quality software were established at organisations like NASA where reliability was critical. They are key in industries like defence, aerospace, embedded and industrial control systems, medical, energy generation and automotive that need to balance complexity, cost and risk.
Across all of these industries, risks remain high, there is always pressure to reduce costs but complexity is only increasing. Automotive design is one area where many different parts of software engineering have to come together, and to combine with mechanical and systems engineering, because like so many once-mechanical systems enhanced by embedded software, it is no longer about designing a vehicle purely for driving. Auto companies are morphing into mobility and consumer electronics companies, having to rely on new and disruptive technologies to build new products – without surrendering any of the responsibilities of safety and performance.
That means the tools that help you manage the product development lifecycle need to be integrated systems that cross multiple domains and disciplines to support a seamless flow of information, and deliver efficiency and accountability across all the steps of that development process.
Car – or complex, connected system?
Assisted, connected and autonomous cars are only the most extreme case; electric and hybrid vehicles are already adding a new level of design problems. Take the power train; it is one of the many real-time systems in the car where precision is vital; you can never miss a signal or fail to respond correctly to an input. But it is no longer a standalone system. If you are capturing energy from braking to charge the batteries in a hybrid power train, you have to incorporate more sensors and look at energy optimisation and battery drain across the entire vehicle because that affects driving range. That also needs to be integrated with the infotainment systems that combine information, control and navigation for the driver. This is the point where the new connected car features combine with the traditional personal entertainment options and the human interface with the car, and it is vital to design that interface and that experience so it does not overwhelm the driver by adding complexity that causes accidents.
Integrating all those dimensions without compromising the key functions of each system, or introducing security issues, is a significant software engineering challenge.
Cars might have started out as mechanical devices, but now they are hugely complex software stacks with millions of lines of code that just happen to have wheels. Few other systems require as much software as a car or truck; there is more code in a car than there is in a fighter jet. Today, up to 90 per cent of the 500,000 different requirements for a new car are not mechanical at all; they are electrical and software. And you are not writing that code to build a single vehicle; even though automotive design has switched to common platforms shared between different models, there are dozens or even hundreds of variants of those individual vehicle platforms. That means you can no longer treat them as a collection of mechanical systems that you prototype and design separately and then bring together as a final integration step; you have to model and create and test and validate the physical systems, in software using simulations, in tandem with the software that interconnects and controls them.
Software development is just one phase in a process that starts with planning the overall architecture and system design, and defining the components in the system. Instead of being heterogonous and fragmented, software and hardware needs to be developed in parallel, with strong integration between the mechanical and electrical components and the software models that make up the overall system throughout the development, so you can validate them together. This model driven development means that systems engineering that has been happening in separate domains like the power train, safety systems and infotainment now needs to apply across all those domains.
New vehicles combine the mechanical and electrical systems you are used to managing with Product Lifecycle Management tools and the electrical and software systems that Application Lifecycle Management tools support. Delivering those new vehicles effectively, on the schedules that customers are demanding, without compromising on either safety or innovation requires tools that integrate and bring these worlds together, and that supports key best practices.
With large teams of software engineers working on the logic and code of multiple systems, there needs to be clear accountability for who is responsible for all those systems as development scales, and regression testing is required to make sure none of the changes made introduce any dangerous side effects. For efficiency, that may need to be automated with continuous integration to validate that the overall safety of the code—across all the different variations of the vehicle platform you are building—has not been degraded by the changes. At any point, you might need to go back and ask who approved a design, which combination of components were tested together or how any defects discovered were prioritised, so you need tools that give a view across all the domains of mechanical, electrical and software control systems in the vehicle.
To keep up with the pace of the industry, automotive development has to include large amounts of simulation, capturing and replaying the data from testing of physical systems to validate every software change, in a way that allows for compatibility and reuse across a wider range of cars, vehicle platforms and variants. For autonomous vehicles and assistive systems, data collection and testing will also have to cover all the territories where vehicles will operate, which might have different driving cultures as well as different driving and safety rules.
Most automotive recalls are related to software rather than to hardware in the vehicle, so increasing quality through better software engineering is vital to avoid the financial costs, and the impact that recalls have on car manufacturers’ reputation.
Testing, verification and validation of all these models has to happen in an integrated way, with software development tools that integrate with PLM systems and are themselves integrated to help with the visualisation of requirements, specifications and information flowing between the different models as a consistent process rather than as a series of discrete steps. That needs to continue all the way from proving the feasibility of a concept, to implementing and optimising the whole system, and increasingly, past the point of shipping. And you have to do that at a faster and faster pace.
Speed and stability
Product development cycles for automotive have been shrinking for a while now; companies have to introduce new vehicle lines or just as importantly new features, even faster, even though there is a continuous stream of new components to deal with, which may have different properties and behaviours. The pace of technology sometimes moves faster than automotive companies can easily digest, because it is not just a question of adopting new components and technologies; it is also the time and cost of integrating and validating them.
Drivers are keeping their cars for just as long, but they have become used to the speed that consumer devices improve at, with annual updates and frequent releases of new apps. There is a demand for the same pace of improvements to the cars they buy, either as new features in the vehicle or to support new accessories. And regulatory changes may also mean that you have to continue development on a vehicle long after launch.
Treating development as a science and an engineering discipline is the only way to cope with this combination of increasing complexity, increasing pressure for cost efficiency and increasing pace. That requires software engineering practices that follow rigorous, structured processes.
If you can close the loop so you move seamlessly through gathering requirements, building, testing and validating code against those requirements and generally improving repeatability in development, you can improve productivity, efficiency and accountability.
The automotive industry is moving towards standardisation, through the growing number of ISO specifications that cover safety, ergonomics, performance, environmental issues and test methods, and through partnerships like AUTOSAR (the AUTOmotive Open Systems Architecture). To be sure you are complying with those standards, you need to put certified software development processes in place.
The right tools and techniques can reduce costs that would otherwise rise as software becomes an ever more significant part of the development process, by increasing efficiency and accuracy. They can help present the requirements, specifications and even the code in ways that are easier for software engineers working on them to read and understand. They are also key to commoditising some of the software development load, by allowing reuse of software components.
In theory, reusing software components between vehicles and vehicle platforms, and even across engineering domains within a vehicle, should reduce costs and development time and increase quality. In practice, it is more complicated because making those components suitable for reuse in all those different scenarios means more development up front, more dependencies to deal with and more testing and validation to be done. But software re-use is another key part of the new approach the automotive industry has to take.
Digitize, design, disrupt – or die
Most of the vehicles on the road today grew up from the power train out, but the world is coming at vehicles from the outside in now; that means the way vehicle design is done has to change to fit this new world, which is only going to get more demanding. There is no room for ad hoc, one-off coding. Instead, you need an integrated approach to end-to-end system design, where software development is another engineering discipline to master, and you need tools that handle the complexity of embedding software in hardware products.
When automotive companies think of themselves as mobility and consumer experience companies, what it really means is that they have to be professional software companies as well. That demands integrated product design and development systems that cover the entire product lifecycle, both mechanical and digital, from idea, to design, to manufacturing, to maintenance and repair, to on-going updates and improvements, flowing information forward for efficiency and productivity and backwards for accountability and traceability.
The increasing pace of disruptive change—in both technology and business models—demands tools that support these new and more agile ways of working, as delivering new business value becomes the only way to keep any competitive advantage. Indeed, when entire markets can disappear with a single innovation, improving business and technical agility can be the only way to survive. Ever more products are neither purely hardware nor software but a hybrid of both, and as they get smaller, smarter, more reliant on embedded software and microprocessors, as well as more interconnected, product complexity is increasing massively. At the same time, customers expect individualized products, ordered online, delivered in next to no time. If you cannot do that for your customer, someone else will.