System Architecture
Mechatronic System Architecture
I want to spend a few words on how I see mechatronic system architecture. A lot of companies use the titles system engineer or system architect, but they don’t always mean the same thing. I don’t intend to clear everything up here, I think there are as much opinions on this as there are system architects. But knowing how I see and understand this discipline tells you something about what I can do for you. So here is my definition of mechatronic system architecture in a nutshell:
The goal of the mechatronic system architect is to use the available resources as efficiently as possible to get the best result, after carefully defining what the best result is.
The first responsibility of the mechatronic system architect is to define the goal of a system or project, taken into account not only the user perspective, but also the business proposition and design consequences. Knowledge of the domain, such as market roadmaps, are required to make a good estimation of the value of a design for the intended end user. It is important to understand not only what customers want, but also how much they are willing to pay for it.
After defining the desired result, the design process can start.m
The desired result is often the best performance with respect to precision, but can also relate to speed, cost, dimension or other parameters. In order to achieve the result in the most efficient way, a deep understanding of the system is required: what drives the behaviour and performance of the system. From this understanding choices on where resources are spent, for example on better sensors or on a better mechanical design, can be made. Since resources are always limited, whether it is in time, budget or availability of people, knowing where resources have the most impact is essential for a good system design. This approach is both relevant for the design of new systems as for the improvement of existing ones.
It is the role of the mechatronic system architect to translate the wishes of the customer/stakeholder into clear user requirements, both for performance as for cost, and translate the user requirements into design specifications. Clear communication between the system architect and the customer, and between the system architect and the developers is essential.
The practice of mechatronic system architecture comes with making the understanding of the system quantitative. This often involves making an error tree or a system model. Using a Value of Ownership approach can help taking into account the context of the system, such as factory costs. I have experience in using different software for making these models, but I believe in starting as simple as possible to get a feeling of the different elements, and only dive into the details where and when the design requires this.
