The need for software systems engineering
One of the ‘big-picture problems’ I came across while consulting on software engineering in the automotive world was the relationship between systems engineering and software engineering. Traditionally, automotive systems engineering has focused on system attributes such as power, weight, performance and cost, to name but a few. Software has been treated as a separable component of the system by systems engineers.
The OEM for whom I consulted had adopted the RFLP systems engineering paradigm: Requirements, Functional Architecture, Logical Architecture and Physical Architecture. The principles of RFLP are that use cases and requirements are collected together to determine functional requirements. These are used to produce an architecture for each (set of) function(s). Parallel functional architectures are then integrated into a logical architecture that composes related functional architecture elements together into related logical units that reflect the conceptual architecture of the intended product. However, the logical architecture should remain implementation independent. Physical architecture includes the technology domains that will contribute to the realization of the end product, eg mechanics, hardware, fluid dynamics, and so on. As such, RFLP isn’t substantially different from other systems engineering paradigms, such as CAFCR.
The problem with the customer’s implementation of RFLP was that the P phase focused only on mechanical and hardware specifications and architecture. Software architecture wasn’t addressed at the systems engineering level. The result was a system that was decomposed to the ECU/CPU and actuator level before software architecture began to be considered. As a consequence, in a vehicle with 100 ECUs, there were effectively 100 software architectures.
Clearly, 100 ECUs aren’t going to operate entirely independently – they’ll have to communicate with each other. And indeed, such communication was facilitated by the hardware architecture. However, in terms of software architecture, the relationship between interdependent ECUs was loose and informal. For example, it was well known that within the software ‘architecture’ of a particular range of vehicles, there were eight different sources of speed measurement.
Treating software as a separable component of a vehicle has worked for the last twenty years or so and has allowed automotive OEMs to continue to design and build complicated vehicles by utilizing their supply chain. Tier-one suppliers could pursue their given goals, loosely coupled with other suppliers, with the OEM merely integrating and testing the associated deliverables. In previous generations of vehicles, less than 10 percent of the in-vehicle software was produced by the OEM for whom I worked, the rest being sourced from multiple suppliers.
With the advent of vehicles as cyber-physical systems, this approach is no longer adequate – a fact recognized by ‘my’ OEM. Cyber-physical vehicles are no longer complicated, they’re complex, with everything that that implies. This complexity demands a different approach to software architecture for reasons highlighted by a simple analogy: if you’re walking around bare-footed and you happen to stand on a sharp object, perhaps a fragment of glass, your autonomous nervous system will immediately act to take the weight off your foot. However, the job of removing the glass from your foot requires a system-wide response led by your central nervous system. In a next-generation, potentially autonomous vehicle, a puncture while driving will require a similar kind of response – local mitigation followed by system-wide adaption. This can’t be achieved by treating software as a loose collection of separable components.
To realize cyber-physical vehicles, and in fact, cyber-physical systems of all kinds, software must be treated as an equal player in systems engineering. In RFLP terms, the P phase must include not only tangible physical domains such as hardware and mechanical engineering but also intangible software engineering. It must be possible to decompose a logical architecture into interdependent physical architectures by building on and trading off the strengths and weaknesses of each contributing domain equally.
As we move from a world of embedded systems to one of cyber-physical systems, and systems-of-systems, software is no longer merely a separable component of the system. Or, as I liked to tell my customer, software is not a component of a vehicle – rather, a vehicle is a component of a software system.
