Today’s complex ‘system of systems’ driving need for sophisticated tools, detailed modeling, data continuity

by Bill Schweber, Jaffa Engineering, LLC

It’s not news that many of today’s products are actually a complex “system of systems” consisting of two, three and more semi-independent subsystems, each with its own complexity and intricacies. What has changed is the dramatic degree to which these constituent systems are now interrelated at more and higher levels.

There are many factors producing this change. First, systems can do more due to advances in electronic and mechanical component functionality, available materials, and software, all driving user expectations. Second, modern technology, especially embedded software, allows the various systems to be linked and managed in real time at the highest levels. This means that the design, operation, and actions of any individual system have impact and repercussions throughout the larger system of systems.

For project teams, there are major implications of such integrated, linked systems of systems, and these impact the entire design and implementation process. No individual or even team can grasp the totality of the design’s big picture as well as detailed subtleties. This, ensuring functionality and design integrity, while balancing tradeoffs versus design objectives, can quickly become an overwhelming challenge without proper support and tools.

Equally daunting, there’s a huge “ripple effect” which occurs as a modest or minor change in one system unintentionally and unpredictably affects performance and operation of another system. You might call it an extreme manifestation of the law of untended consequences. Further, any design tradeoffs or compromises made in one system may have serious consequences in a connected system, yet which are not obvious or even remotely perceived. The systems of systems situation does not apply only to obviously complex products such as aircraft or missiles, as even the design and manufacture of mass-market consumer products such as automobiles has all the systems of systems characteristics.

Consider the electrical system of a vehicle: twenty or thirty years ago, that electrical system supported the starter, ignition, battery charging, lights, and dashboard; the most-sophisticated electronic function in the car was the radio. Today, the electrical system must also control and interconnect power windows, doors, and mirrors; navigation and guidance; anti-rollover systems; the broader ADAS (Advanced Driver Assistance Systems); safety features such as cameras and lane-drift warning;  smart and regenerative brakes; advanced transmission control; tire-pressure monitoring; entertainment functions; USB power outlets; wired/wireless connectivity; and many more — often totaling well over one hundred embedded microprocessor and other smart interfaces plus several internal wired networks, Figure 1.

 

If the vehicle is an EV/HEV (electric/hybrid vehicle), there’s also a complicated battery system. Further the autonomous vehicles being developed add many more functions such as advanced image-capture plus huge amounts of processing capability. All these electrical and electronic systems mean multiple wiring issues and harnesses which range from heavy copper cables for DC power down to optical, twisted pair, and wireless connections for the various internal car networks.

Wrestling with Complexity Before It Overwhelms

What used to be known as “systems engineering” has, of necessity, become much more than just that. Given the inherent complexity of system of systems designs, what approach and tools can be used to manage the situation and project? The answer starts with a clear perspective of all the building blocks that form the system hierarchy Figure 2.

Going from left to right (hierarchically, from top to bottom), there are four major entity types:

• The system of systems or final product itself, which can be an aircraft, automobile, or an entire defense capability;
• Each system within the overall system, which is a set of integrated, collaborating function which deliver specific features such as propulsion, navigation, or communications;
• The units which comprise each system, forming a set of elements within an enclosure that work together to deliver one or more functions, such as a sensor, an LRU (line replaceable unit), or even a rack;
• Finally, the elements or components which are the constituent blocks of the units, such as embedded software components, memory chips, or COTS (commercial off the shelf) connectors.

Of course, what constitutes a “system” depends on your perspective, Figure 3. An aircraft designer and manufacturer considers the entire aircraft to be a system of systems, with one of the many systems being the jet engine, while a jet-engine company views the engine itself as a system of systems – and both are correct.

What designers need is a highly organized, formally structured top-down and bottoms-up method for specifying, designing, implementing, and verifying these hierarchical entities. This is much more than just a shared database of design details, BOM, and other data. Instead, it defines and then links top-level requirements to bottom-level implementation, allow assessment of tradeoffs and implications of changes at any level.

It must also link all aspects of design, modeling, verification, tracking, and more so that small changes do not “fall through the cracks” with respect to their local and global impact. It must capture any implications of even a modest change to the BOM, a component specification, package form or fit and, equally important, to any low-level, localized software.

For example, changing from one vendor’s LCD or LED display to a different supplier seems like a fairly straightforward process, in principle, but there may be a set of associated changes. These may be related to readability and brightness, mounting dimensions, production assembly, power -supply requirements, power cabling and connectors, data cables and connectors, thermal dissipation, data formatting and protocol, and software drivers. There are also documentation, purchasing, and inventory implications if the new display is not on an approved component list, available in the time frame needed, or priced within budget.

Advanced Tools Address Evolving Needs

It’s one thing to talk about a system of systems and how to manage the various elements across both horizontal and vertical perspectives, Figure 4, it’s another to actually devise tools that are properly focused on the how to accomplish this.

Even the seemingly mundane and very tangible function of engineering a car’s wiring harness now needs a suite of applications such as Capital® from Mentor Graphics. This package and its many functions focus on all issues associated with electrical distribution systems and wire harnesses, Figure 5. It encompasses an extended flow from platform concept and electrical architecture definition, to detailed design and wire-harness manufacturing, as well as in-service maintenance documentation.

Mentor’s Capital® includes the functional abstraction, which is independent of actual implementation. For example, a low-level function may be realized in hardware or software. Functional abstraction maps functions and signals to resources, thus optimizing the implementation versus target parameters while verifying design integrity.

To do this, Capital® implements model-based systems engineering (MBSE) principles, which use one abstraction as a model for another one (usually at the next, more-detailed level), generating the new abstraction from the previous one. Doing so allows for data coherency and continuity, leading to algorithm-based, software manageable interactions between the abstractions.

It’s also critical to be able to import data from third-party modeling tools to ensure full awareness of all design subtleties. This means that appropriate outside data, models, and knowledge is available to the Capital® application, thus eliminating gaps, re-work, and sources of errors.

Benefits of Faster, Better, Cheaper – and Beyond

There’s no doubt that system of systems design is inherent in today’s increasingly challenging engineering projects. To address and fulfill the needs of these projects, Mentor is following model-based systems engineering principles, delivering federated tools that encompass all aspects of the system of systems landscape from concept to design, through validation, and even into manufacturing.

The result of seamlessly integrating model formats is digital continuity through all stages of design and delivery. Such data coherency recognizes the fact that design demands of systems of systems now exceed the ability of any individual or even group to grasp the scope and details of the entire project. Therefore, a highly structured yet flexible multidisciplinary approach is mandated, with a powerful application to implement it.

Data coherency brings many benefits beyond just automation. It enables simulation, checking, and verification; assessment of tradeoffs versus constraints as part of the optimization process; sharing and reporting of design implementations and changes; re-use and re-purposing of existing design functions;  and supply-chain integration.

Also obvious are the broad benefits related to the never-ending challenges of all large projects: achieving cost-effective, correct (verified and validated), and on-schedule results. There’s an old engineering maxim that you can have a project done right, done right away, and done cheap – but you have to pick just two of three. What the structured system of systems approach with overall data coherency does, as represented by Mentor’s Capital®, is allow the design team to get all three simultaneously to an extent otherwise not possible.

Finally, there’s another major benefit, but one that is often not fully articulated but nevertheless vital: it promotes innovation. System of systems applications such as Capital® gives engineers the capability to be more innovative, and be so earlier in the cycle – and that’s where the competitive edge lies. It also boosts engineers’ job satisfaction, which is critical to getting their best effort, since they don’t have to spend time on drudge work of transcribing data, manually bridging gaps across platform or design functions, and checking for inconsistencies and errors.

 

 

About the author

Bill Schweber is an electronics engineer who has written three textbooks on electronic communications systems, as well as hundreds of technical articles, opinion columns, and product features. In past roles, he worked as a technical web-site manager for multiple topic-specific sites for EE Times, as well as both the Executive Editor and Analog Editor at EDN.

At Analog Devices, Inc. (a leading vendor of analog and mixed-signal ICs), Bill was in marketing communications (public relations); as a result, he has been on both sides of the technical PR function, presenting company products, stories, and messages to the media and also as the recipient of these.

Prior to the MarCom role at Analog, Bill was associate editor of their respected technical journal, and also worked in their product marketing and applications engineering groups. Before those roles, Bill was at Instron Corp., doing hands-on analog- and power-circuit design and systems integration for materials-testing machine controls.

He has an MSEE (Univ. of Mass) and BSEE (Columbia Univ.), is a Registered Professional Engineer, and holds an Advanced Class amateur radio license. Bill has also planned, written, and presented on-line courses on a variety of engineering topics, including MOSFET basics, ADC selection, and driving LEDs.