Fields marked with a * are required


Mechatronic Management (Part 4): Integrated System Engineering Aspects

This series of four posts looks at the management of items, data and bills of material for mechatronic products. It is split into mechanical aspects, electrical aspect, software aspects and integrated aspects.

Time flies, right? I started this series on Mechatronics Management back in April thinking it would be straightforward. But I have to admit that this post in particular has been the most challenging. And as a result has taken the longest to develop. You see, as I traveled to different conferences and listened in on various webcasts, the list of things related to integrated aspects of mechatronics management has grown and grown and… well… you get the idea. But enough about the backdrop, let’s get into the details.

What Do You Mean by Integrated Aspects of Mechatronics Management?

So far in this series, we’ve talked about mechanical, electrical and software aspects. Each of those engineering disciplines have their own design artifacts that need to be managed and that have specific interrelationships. But there are also some cross relationships between these discipline specific representations also that need to be managed. And there are also some processes specific to system engineering and integration efforts that need to be supported. In my mind, those are the artifacts and processes that fall into an integrated aspect category.

Artifacts and Processes for System Engineering

Beyond the traditional mechanical, electrical and software engineering disciplines, there are system engineers whose primary responsibility is to make sure that systems and sub-systems that span those traditional disciplines work in the end and fulfill the functions originally assigned to them. The following are some of the artifacts and processes that they have to manage.

Requirements Breakdown and Allocation

Requirements are a pretty standard issue within product development. Why would they be involved in system engineering? Because requirements that start at the very top-level in a product are not specific to any single discipline. In fact, requirements at that level often have to be fulfilled by design from some combination of those disciplines. The system engineer coordinates the breakdown of those requirements into piecemeal ones that can be fulfilled by systems, then sub-systems then into assemblies and sub-assemblies. Eventually, after they have been broken down many times, requirements can be assigned to something that is discipline specific. But those discipline specific designs must work in concert to satisfy higher level requirements.

There are many different systems that can manage a requirements structure. However most do not allow for allocation across a full mechatronics definition due to the fact that they do not represent the designs to a granular enough level. Electrical representations of PCBs stop at the board and component level when requirements might be allocated to specific traces. Software representations stop at the compiled code when requirements might need to be allocated to libraries, specific calls and other aspects of raw code.

Functions Development and Allocation

An adjacent approach to requirements management is to develop a functional architecture that generically and theoretically satisfies a requirements structure. As you might imagine, one requirements structure might be satisfied by many potential functional structures. Once fully defined, individual functions are allocated to specific systems, sub-systems, assemblies, sub-assemblies and items. It’s very similar to the requirements breakdown and allocation but with a different take.

Regardless, this sort of process and the resulting artifacts and relationships are also managed by the system engineer. And like the requirements that were described in the previous section, they could be allocated to items that are mechanical, electrical, software or some resulting combination.

When it comes to systems that manage and support functions, the list is fairly few. There are some languages such as SysML that try to do the job fairly well but ultimately they are fairly disconnected from the systems, such as PLM, PDM and SCM, that actually house the artifacts representing items in the system. As a result, much like the situation for requirements, those functions cannot be allocated to them directly.


Another artifact that is used is called an interface. It essentially acts as the definition that is used to integrate two systems in a product. A mechanical example could be a mounting hole pattern. An electrical example could be a timing standard used for two PCBs to pass signals back and forth. A software example could be an agent or service that communicates between two pieces of software. But modern-day interfaces are definitely cross-disciplinary. For example, an interface between two systems on a satellite might have a mating plate, specifically defined electrical connectors and detailed software protocols.

Unfortunately, cross-disciplinary interfaces suffer from the same lack of support that requirements and functions also do. And again, it is due to the lack of granularity in the design representation within a single system. Most interface definitions are reduced to a specification which may point or link off to mechanical, electrical and software definitions that each exist in PLM, PDM or SCM systems separately.

Managing Verification and Validation

Another major piece of system engineering is often forgotten but is terribly important. Towards the end of the design phase, system engineers need to make sure that all of the items, sub-assemblies, assemblies, sub-systems and systems all do exactly what they are supposed to do. And because the design phase of the development cycle is a whirlwind of work-in-process, that can be very difficult to do. As a result, system engineers have adopted a highly disciplined approach that is highly configuration managed. Everything, from requirements, functions, interfaces to design artifacts, is configuration managed. And there are procedures in place to ensure that an exact version and iteration of a requirement is exactly fulfilled by an exact version and iteration of a mechanical item. Ultimately it becomes a hugely complicated checklist through which progress must be tracked and managed. And if an item goes through a change, then anything related to that specific item must be verified and validated again.

What systems help do this? Not many. The list of systems actually enable systems engineers to track and manage this process is very very small. As a result, they have to do most of it through spreadsheets. Hugely, complicated, mind-numbing spreadsheets.

Conclusions and Questions

Actually, this isn’t the end of the story. In this post we’ve just covered the system engineering parts of mechatronics integration. There’s actually a whole other side of the story in terms of integrated detailed design of mechatronics products. But that’s a touch too much to include in this post. It deserves its own.

In conclusion, with many of today’s products including mechanical, electrical and software aspects in it, there’s a large need for system engineering discipline to ensure it all works before design release. This includes artifacts and processes like requirements management, functions management, interface management and verification and validation.

With all that said, did I miss anything from a system engineering perspective? I’d be a little surprised if this covered most of the artifacts and disciplines that are related to system engineer. Sound off and let us know what else is involved.

Take care. Talk soon. And thanks for reading.

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.

Like this post?

Sign up now to get more like it

Fields marked with a * are required