Mechatronics Management (Part 3): Software Aspects

June 10, 2011 | Categories: Lifecycle Insights Projects, Software Applications and Systems

 

 

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.

Mechatronics Management (Part 2): Electrical Aspects

April 27, 2011 | Categories: Lifecycle Insights Projects, Software Applications and Systems

 

 

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 aspects, software aspects and integrated aspects.

In the minds of many, managing electrical aspects of products has, well, already be done. Meaning there have been approaches and technologies that have been around for some time to manage the artifacts representing electrical components. But actually there have been some relatively recent advancements in the technology that, by and large, isn’t commonly managed centrally today. Let’s take a look.

Managing Electrical Aspects of the Product

When you start talking about the electrical side of the house, things tend to be a bit more complicated compared to the mechanical side of things. What is considered a part can be dramatically different depending on the type of electric item you’re discussing. Here it makes sense to split up the discussion based on the type of electronics being developed.

Managing PCB Schematics, Diagrams, Layouts and Libraries

Printed circuit boards (PCB) are used pretty frequently in today’s products. The design of a PCB often starts with a 2D logic diagram that represents the functions of the PCB. Next the design moves on to a 2D schematic, where the connections between the different board components are symbolically shown. And finally, the layout shows a detailed view of the placement of components and the path and layer for each trace in the board. From a manufacturing or sourcing perspective, the lowest level items on a PCB are the components (resistors, etc.) and the board. However, there is information embedded in these design artifacts that describe a deeper level of granularity in the board itself: the traces that connect the components on the board. To further complicate things, the components and connections between them are represented in both the schematic and layout. That means if that connection changes in one, it should change in the other.

Today’s PLM or PDM systems often recognize that the diagram, schematic and layout all essentially represents the same electronics assembly. And as such, they create links between them. And while integrated tools recognize that a change to a connection in the schematic should propagate to the layout, most PLM or PDM systems do not. Furthermore, the information about the connections themselves that is embedded within these design artifacts are often not extracted into the PLM or PDM system. From a Bill of Material (BOM) perspective, most PLM or PDM systems will extract the counts of the different electronic components, creating a flat list with quantities. The diagram, schematic and layout are often attached to the top level board assembly.

What shouldn’t be lost in all of this details is the fact that most PCBs are assembled almost completely out of off-the-shelf items. As such, a centralized library composed of approved parts lists generated by the procurement organization is used to identify which components are OK to use for designers and engineers.

Traditionally, PLM and PDM systems have managed this library as a single item that can be downloaded to a desktop. From there, the ECAD or EDA application accesses the library directly.It can certainly work. However a fair amount of functionality exists in PLM and PDM systems to manage libraries of parts, to manage change across those libraries and to promote reuse so that higher volume discounts can be achieved. By managing the electronics component library as a single item, none of those things can be proactively managed. Ultimately, electronics components would be managed as individual items, just like mechanical parts, in PLM and PDM systems.

Managing FPGA Programming

In many circumstances, manufacturers want to optimize processors to do a specific job. One option is to custom build application specific integrated circuits (ASICs), but they are extremely expensive because they require custom dies and manufacturing runs. The number of ASIC manufacturers in the world can probably be counted on a couple hands. So, instead, manufacturers often use field programmable gate arrays (FPGAs). This type of chip is a off the shelf component that can be programmed with custom logic to perform specific jobs more quickly and efficiently than generic chips. However, since they are off the shelf components, they aren’t nearly as expensive as ASICs.

So how are FPGAs programmed? Traditionally, manufacturers would hire programmers to code the logic of these chips. And managing that environment looks very much like a Software Configuration Management (SCM) problem. But times are changing. There are new software applications that will let a user create a logic diagram and then, in an automated fashion, generate the code to program the FPGAs. This is an advancement in terms of enabling everyday engineers to define the logic they want without working through a programmer, a proxy who often doesn’t understand the engineer’s design intent. This approach is sometimes referred to as visual programming. Now don’t get me wrong. The code generated by these software applications aren’t perfect. However they often enable the programmer to just check the code instead of writing it themselves. And that can be a huge time savings for an expensive resource.

As you can imagine, either programming directly or using a visual programming approach will generate a number of design artifacts that should be centrally managed in some manner. More often than not, this type of deliverable though is managed as a generic artifact, just like a word document, and as a result doesn’t have any automated association with the FPGA item it will affect. Furthermore, none of the information or intelligence embedded in these artifacts are exposed to the broader audience. But most importantly, the logic of the FPGA is disconnected from the logic of the PCB on which it resides. Combining the two holds the potential to perform more realistic simulation. However, let’s hold off on that discussion for the integrated aspects post in this series.

Conclusions and Questions

In summary, there is a great amount of complexity in managing the design artifacts used to develop PCBs ranging from schematics, diagrams and layouts. They are each connected and change from one should propagate to the others. Today’s PLM and PDM systems manage these representations as an interconnected set, extracting the BOM from them, but infrequently extracting more granular information than that. From an FPGA perspective, most design artifacts are managed by PLM or PDM systems as unintelligent files. Instead, it is more frequent that the artifacts for FPGA programming are managed with Software Configuration Management (SCM) systems.

Time to sound off. What are you using to manage these artifacts today? Do you think PLM or PDM systems manage these design artifacts to enough granularity or is there still room for improvement? Weigh in and let us know what you think.

Mechatronics Management (Part 1): Mechanical Aspects

April 21, 2011 | Categories: Lifecycle Insights Projects, Software Applications and Systems

 

For the past three years, I’ve headed out to Phoenix AZ for the Congress on the Future of Engineering Software to talk with numerous providers and users of engineering software. The discussions are always pretty forward-looking, almost bleeding edge instead of leading edge. In the analyst briefing on System Modeling and Analysis, which was led by Allan Behren (who goes by the twitter handle @AllanBehrens), one of the engineering IT leader for For, Richard Riff, made a statement that made my ears perk up (the following is a paraphrase).

The Ford Fusion has 142 processors in it. We no longer split up systems for development, hand them off to various teams and then integrate at the end. We actually work a lot more like a software company where we compile builds on a weekly basis. Everything is so integrated we just can’t wait until the end of development anymore.

Richard, please correct me for any misstatements I might have made above.

From my perspective, Ford isn’t alone in this stance. There is so much software, processors and electronic systems in new products today that manufacturers are having to rethink their development processes. Which brings us to an interesting question: how can enterprise systems, like PDM and PLM, best support mechatronics development? Today, it seems like there’s an increasing focus on how all of the product’s items and the artifacts that describe them should be managed in one place. But there can be quite a wide range of support capabilities that are offered.

Let’s take a look at each level and understand the advantages and benefits of each.

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.

Managing Mechanical Aspects of the Product

For the most part, the capabilities of enterprise systems like PLM and PDM in managing mechanical items, data and BOMs is one of the most mature in the context of a mechatronic product.

Managing Assemblies of Mechanical Components

Many CAD applications use what I like to call a federated approach to building up an assembly. Each mechanical component is often represented by a single part file. Those separate part files are then placed together to form an assembly, which is a separate file also. As those individual parts and assembly files change, you run into a configuration management problem. You need to know which version and iteration of each was used on a particular date for testing, a ramp-up run on the shop floor or was sent to a supplier. Most PLM and PDM systems extract and understand these relationships between these artifacts.

Managing Design Deliverables

Also, individual deliverables such as engineering drawings are separate files. These files have direct relationships to the parts or assemblies that they represent. And the same configuration problem that exists between part and assembly files also exists with their deliverables. Most PLM and PDM systems understand and manage these relationships.

Extracting Information for the Enterprise

In addition to managing configuration issues, the information in these artifacts are extracted and used for broader enterprise purposes. The structure within the assembly is often used to generate an as-designed bill of material (BOM). Additionally, the solid models of the assemblies or parts can be extracted for visualization purposes.

Conclusions and Questions

Today’s products are increasingly mechatronic. This series of four posts take a look at different aspects of mechatronics management. From a mechanical perspective, it is important to manage the configuration issues for the relationships between parts and assemblies, items and their deliverables such as drawings and to be able to extract information from these artifacts like BOMs and visualization models for the rest of the enterprise.

Now it’s your turn to weigh in. What’s missing in terms of capabilities for the management of mechanical design? Sound off and let us know what you think.