Ever since I’ve been an engineer, technical designers have been dealing with handoff issues. What do I mean by handoff issues? In track and field, when a relay runner hands the baton to another runner in the exchange zone, it can happen that a runner bobbles the handoff. This can cause the receiving runner to slow down and thus cause that team to lose the race. If the baton is dropped altogether, consequences can be dire. In engineering, when information is incorrectly passed from one team to another, consequences can be just as problematic.
The problem in the days of paper was that the second team (the receiving team) had to read the paper that was handed to them and, from that reading create an interpretation of the intentions of the first group. Project success rested on the fidelity of that interpretation. Projects that succeeded interpreted the first group’s intentions correctly; failed projects most likely didn’t.
The same was true for handoffs between devices. If the information transfer was successful, then the message got through. If it was not, then the communication failed. A major potential for failure often exists at these interfaces, whether between organizations or between devices.
With the advent of the digital age, we’ve been using software environments to create our designs. However, no tool suite is comprehensive enough to capture the design from inception through production. I’ve personally been involved with projects that successfully met the systems engineering milestones, but when we transitioned the design to the detailed stage, things didn’t pan out. Let me tell you about a time when I was on a project designing cables.
The cables had been designed using capable tools operated by capable engineers—and yet, the cables produced were incorrect and had to be redesigned. In some cases, the cable designs were redone more than once. How could that be? The downfall was unclear communications between the systems engineering group and the hardware group. Too much of the intent was left to interpretation and not captured on a solid and traceable digital information flow. This was because the tools did not interconnect, and we reviewed artifacts that had to be interpreted.
So what can be done? I use the GENESYS model-based systems engineering (MBSE) tool to perform the systems engineering analysis. In the MBSE environment, we conduct high-level architectural design, identifying what the major aspects of the design are, and we repeat this process a few times until we get to the point we need to transition to detailed design using the skills of electrical and mechanical engineers. In GENESYS, I model concepts at multiple levels.
I first identify that two things logically connect and then I use the INTERFACE element class. If I perform a decomposition that only involves more logical aspects, I decompose the parent INTERFACE into lower-level logical connections—which are also INTERFACES. The next level of modeling addresses physical aspects modeled with the LINK element class. The physical LINK can be further be refined or decomposed by other LINKS. The information exchange itself is modeled using the ITEM element class. ITEMS are output by functions and may be used to trigger other functions. ITEMS are transferred by LINKS and LINKS comprise INTERFACES.
At the end of my effort or the effort of a multiple-person SE team, we have a model that identifies the need for cables to connect to hardware elements, and I know what information has to be transferred. Generally, as a systems engineer, I don’t select the actual cable by part number, number of conductors, backshells, or connectors. The hardware engineers will make those selections. Wouldn’t it be useful if the MBSE artifacts were clear such that the hardware engineer understood design constraints imposed on the cable, such as bandwidth, electro-mechanical interference, electro-mechanical coupling, operational conditions (humidity, heat, and corrosion), connector pin assignment, arrangements in the cable, and required mating connectors? How about identifying verification tasks enabling each team to conform to the verification tasks?
Today, design details are available in systems engineering artifacts, but they don’t transfer directly from the systems engineering design tool environment to the hardware design tool environment. What would be most advantageous would be automated connections between MBSE and hardware tools. In the not too distant future, MBSE tools should be able to format MBSE interface data that allow the hardware engineer to design cables that fully meet the project objective. As hardware engineers perform their analyses, the results should be exchanged with the MBSE tool to capture the design journey, thereby enabling future changes to be made expeditiously and accurately.
Of course, there isn’t a silver bullet for all classes of errors in every situation. (See past blog posts: Is there a systems engineering silver bullet? Part I: Process and Tools, and Is there a systems engineering silver bullet? Part II: (Not) Reinventing the Wheel.) But if I’m right, and a predominance of errors do occur at the interface level, then an automated, seamless connection from MBSE and hardware tools will make great strides toward eliminating interface problems.
I’m looking forward to eliminating the uncertainty of handing off my MBSE analysis baton to hardware engineers in the old school manner, and look forward to doing so through integrated engineering environments. This, I think, is the next step in the digital engineering journey.
Happy Engineering!
