|
Modern vehicles (automobiles, trains, aircraft, or ships) are obviously complex. The vehicle control architectures (VCA) in luxury automobiles, for instance, contain 50-80 electronic control units (ECU), all sporting a microprocessor of various capabilities and all communicating over four to six networks. Yet no one is able to say whether there should be 80 or 10 ECUs interconnected by one or 10 networks in an optimal VCA. Not only that, but it also is not possible to exhaustively verify the real-time control systems of modern vehicles using formal methods, or by building physical prototypes and driving or flying them around for a year or two.
We have seen the results of these approaches to verification in the embarrassing stalling of luxury and hybrid cars on autobahns and highways due to improbable, but clearly inadequate, testing for faults occurring within, and increasingly between, ECUs in the vehicles.
The fact that such rough engineering has survived so long in the face of desirable optimization constraints involving cost, performance, reliability, fault tolerance, safety, and liability is rather remarkable in the cost-fixated transportation industries. These faults may have their origin in the specification process as well as design and manufacturing supply-chain processes.
Real-time complexity rising
The complexity of the empirical optimization and verification processes for supersystems (such as the VCA of an entire automobile or airplane) stems, in part, from the interaction of five technologies used to realize real-time control systems: Mechanical, electronic (digital and analog), computer system hardware, software, and communications. Another complexity factor is that the optimization (or verification, for that matter) of a single VCA must necessarily be performed in a realistic context—within that of other vehicles VCAs as well as traffic infrastructure (below). Remarkable as it may seem, the lack of optimization as a specification imperative is all too obvious in the automotive industry.
Real-time systems complexity will rise even further as automobiles begin to actively communicate with each other, as well as the infrastructure, to share information on traffic flow, etc.
Get it together
Two processes that should be twinned in systems engineering are specification and architecture with verification and validation. Real-time control system specification and architecture is a discipline in its own right, but it is only beginning to be used by the early adopter companies to drive their design processes.
At the other end of the conventional and widely-adopted V engineering process (serial design, test, and manufacturing process)—systems integration—lies a very thorny issue: The failure of a control system detected during the verification of an integrated system.
Failures that occur late in the engineering process are always expensive to repair since they require complex, and likely lengthy, system diagnosis, followed by either radical system redesign or cancellation at the point of peak expenditure in the project. It is the job of empirical system architecture to flag and remedy problems, including the potentially catastrophic, in the initial phase of the systems engineering process. Indeed, until catastrophic specification and architecture paths are investigated, the empirical systems engineering process is incompetent and incomplete. The conventional V process, perversely, often seems to be the reverse of a competent systems engineering process.
|
