“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 a system”
Parallel functional architectures are then integrated into a logical architecture that composes related functional architecture elements 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 realisation of the end product, e.g. mechanics, hardware, fluid dynamics, etc. As such, RFLP is not substantially different from other system 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 was not addressed at the system engineering level. The result was a system that was decomposed to the ECU/CPU and actuator level before software architecture began to be considered. Consequently, in a vehicle with 100 ECUs, there were effectively 100 software architectures.
Clearly, 100 ECUs will not operate entirely independently – they will have to communicate with each other. And indeed, such communication was facilitated by the hardware and signal deployment architecture. However, the relationship between interdependent ECUs was loose and informal, i.e there was little software system architecture. 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 vehicle component has worked for the last twenty years, allowing automotive OEMs to continue designing and building complicated vehicles by utilising 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% 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 recognised by ‘my’ OEM. Cyber-physical vehicles are no longer complicated; they are complex, with everything that implies. This complexity demands a different approach to software architecture for reasons highlighted by a simple analogy: If you’re walking around barefoot and 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, 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 cannot be achieved by treating software as a loose collection of separable components.
To realise all kinds of cyber-physical vehicles and systems, software must be treated as an equal player in system 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 system component. Software must be treated as an equal player in and contributor to Systems Engineering.
Read more
An outbreak of hubris
Software is the medium of digitalisation. If you don’t understand software, you have no hope of coming up with a decent digitalisation strategy.
Software is not a component of a vehicle
Automotive OEMs have evolved to become highly efficient outsourcing and system integration organizations. Everything related to a vehicle is thought of as a component, including software. The whole automotive system engineering process treats software as a component of a vehicle. This prevents them thinking about the software as a whole system.
Abstraction versus Vagueness in Software Engineering
Some software engineering teams have a problem understanding the difference between abstraction and vagueness. Since one is essential to the architecture and design of complex systems and the other leads to technical debt and poor software quality, software teams must grok the difference.