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.
When you think about it, managing the software aspects of a mechatronic product is, at least in relative terms, one of the most recent advances in product development. Products have long had mechanical and electrical components to them. However there has been a recent explosion of software in more traditional products in an effort to make them smarter, more efficient, more use friendly and provide all sorts of new capabilities.
Managing Software Aspects of the Product
Like the electronic aspects of the product, the software aspects are complicated to say the least. However it is eminently different in that the end item ultimately has no physical form. There is really no equivalent in terms of manufacturing, unless you think of actually writing code as the analogue. Regardless, if you are writing code then one of the first things that needs to be done is to manage software configurations.
Managing Software Configurations
So what exactly is this all about? The development of modern software is actually very similar to mechanical or electrical design. The software is broken down into modules. Those individual modules are then written, assembled and compiled. Overall it’s very similar to mechanical or electrical design in that individual parts are put together to form assemblies. The various software modules that comprise the overall software end item change at different rates, much like mechanical and electrical parts do. And as a result, the assembled software end item is composed of numerous software modules that exist at different versions. Tracking which software module is at which version is essentially a configuration management problem. Modern Software Configuration Management (SCM, wikipedia entry) systems do all this in an automated fashion across multiple sites for numerous users simultaneously.
The main purpose for this type of system is to ensure that right configuration is correctly tested, verified and flashed into the mechatronic product. And with new software development approaches daily builds (wikipedia entry) are commonplace, this becomes really important. But there are many other reasons also. Just as it is done in mechanical and electrical design, reuse is a huge time saver in the software world. Different existing software modules can be used again in an effort that means there is less net new software to be written and tested. It also means there’s less risk associated with a software end item that is reusing software modules that already exist.
Overall, SCM systems manage the configuration problem that arises when software end items are split up and developed across a team.
Managing the Software Lifecycle
But the story doesn’t end there. Much like any product, software end items have a lifecycle of their own through which they progress. It starts with requirements management, decomposition and allocation. There is then a planning phase where the software end item’s architecture is designed. It is then coded where project management techniques are used. It is also built and tested on a frequent basis. And finally it is released, after which a change management process governs how, when and why post-release changes are made.
This larger set of processes are commonly managed and controlled with an Application Lifecycle Management (ALM) system (wikipedia entry). Furthermore, SCM systems tend to be a subset of ALM systems much the same way that PDM systems are commonly a subset of PLM systems. In that way, there are many parallels between this type of system and traditional Product Lifecycle Management (PLM) systems (wikipedia entry). However there are unique processes and procedures specific to software development that ALM systems support that traditional PLM systems do not support. But these tend to get into workgroup level activities for which SCM systems are used.
Software Management in Mechatronics as a Follower
What may be most interesting about existing SCM and ALM systems how they have been initially developed for application development as opposed to mechatronics development. Make no mistake, these types of systems were initially created to support application development, which ends up running on a desktop or workstation as opposed to a mechanical-electrical product. And at the higher levels of planning, designing and validating a mechatronic product, there are processes and procedures that many ALM and SCM systems do not support. But that conversation starts to get into the integrated aspects of mechatronic development, which we’ll go into much deeper in the next post in this series.
Conclusions and Questions
In the past decade, there has been an explosion of software in traditional mechanical-electrical products. Software Configuration Management (SCM) systems track the versions of software modules that make up a software end item. Application Lifecycle Management (ALM) enable the larger processes and procedures used to develop the software end item. Many ALM and SCM systems were originally created for application development as opposed to mechatronics development and as a result, often do not manage the higher level activities necessary for mechatronics development.
Now it’s your turn. What systems has your organization used to manage software aspects of your product? How much has your organization focused on SCM as opposed to ALM? Sound off and let us know what you think.
Take care. Talk soon. And thanks for reading.
