Developing complex systems and software for embedded or real-time industrial automation applications is a daunting challenge for designers and engineers. Projects require that engineers, developers and controls specialists maintain high quality systems and software, meet demanding schedules and managing complexity, while simultaneously fulfilling safety, accuracy, clarity, traceability and productivity objectives.

Typically, the way this problem has been managed is by selecting specific tool solutions to meet the unique needs of each stakeholder. Although effective, the single tool philosophy may not be enough to fully meet the demands placed on it.

Combining environments, however, can be a powerful strategy to solve the quandary. Ideally, this approach allows users to harness the best aspects of each tool to create a better solution by combining the power of the tools to create an environment that is collectively better than they would be individually.

Such is the case for engineers that select a UML/SysML based Model-Driven Development (MDD)  environment and a Model-Based Design (MBD) for dynamic systems tool (see Table 1 below).

Table 1. MDD versus MBD feature comparison

By combining these best-of-breed solutions, users benefit from an environment that covers the complete process, from requirements to specification, design, development, implementation and test. Notably for industrial automation projects like robotics or stretch blow molding technologies (Figure 1, below), as well as aerospace / defense and automotive applications , engineers that realize the full potential of the MDD/ MBD approach are able to develop robust systems and software in an easy-to-use modeling environment for better overall quality and meet rapid time-to-market goals.

Figure 1: By providing a flexible way to combine the domain specific UML, SysML with model-based design tools such as Simulink, plant and control modeling users can work with the tool that best meets their needs.

Complementary Solution
Most developers have strong preferences about the modeling tools that they use to design new projects. With the days of static paper designs long gone, choosing tools that enhance the workflow, boost productivity and are cost effective are very important organizational considerations.

Companies that select an MDD or MBD solution may not think to combine the two in a complementary fashion; in many cases, the search for a holistic tool environment is based on finding one standalone solution that solves all problems.

Using a combination of MDD and MBD tools, engineers can assure that all facets of the process are covered. The MDD environment covers standard UML 2.0 / SysML based software and systems design and Simulink is the de-facto standard for dynamic systems modeling allowing block diagrams of complex dynamic (mathematical) algorithms to be captured and analyzed.

The combination of powerful MDD and MBD environments form a hybrid-modeling environment capable of capturing requirements, designing systems and software architectures and developing logical and mathematical algorithms while supporting multiple workflows.

MDD and MBD: The Power of Two
The MDD/ MBD combination is powerful because it offers a complete process coverage solution while allowing users to select the tool most appropriate for each activity in the design cycle. With MDD, users can access requirements capture and analyze functions, define systems and software architecture and develop logical algorithms. Each function can be simulated and tested to ensure that they are correct; customized documentation can be generated for enhanced communication and the actual implementation can be realized through production code generation.

With MBD, users can create plant models that define the dynamic behavior of the physical elements that the system will interact with and develop the mathematical algorithms that control these plant models. This can all be simulated in MBD to ensure proper results, code can be generated from the control algorithms for use in prototyping and production while code can be generated from the plant models to be used in hardware-in-the-loop (HIL) testing. 

Requirements Capture and Analysis
Using the MDD process, successful projects always begin by first capturing requirements, and then analyzing them for accuracy. With the MDD/ MBD synergy, users can capture textural requirements in requirements management tools (DOORs, RequisitePro, etc.), or with requirements capture tools (Word, Excel, PDF's etc.) or by using the MDD environment's SysML requirements diagram to capture textual requirements that can then be managed within the MDD environment.

Users can create traceability links between requirements and the SysML / UML and MBD model elements that realize or test the requirements (See Figure 2, below). From there, requirements analysis, coverage analysis and impact analysis can be done.

This includes identifying requirements that are not yet addressed, finding design elements not justified by a requirement, easily finding all design elements impacted by a requirement change providing the true cost of that change and ultimately understand what requirements may be impacted by a design change to ensure that by fixing one thing others are not broken.

Figure 2: Rhapsody Gateway view of a requirement captured in DOORS that has been linked to both Rhapsody and Simulink model elements.

The MDD/ MBD workflow for control systems
The benefits of plugging an MDD environment, such as Rhapsody, into an MBD tool such as Simulink are multifold. First, the synergy enables the different disciplines to use best-in-class tools. Control engineers can work in the MBD environment, and systems and software engineers can use the MDD tools to develop a project or one engineer can use both tools while preserving the natural workflow of the user.

The natural workflow of the Simulink user is preserved, with the ability to access Rhapsody as a block in the Simulink model, enabling engineers to model the architecture, behavior and logic of blocks representing electronic or embedded systems using a full UML / SysML environment. Additionally, UML/SysML-based MDD designs can be tested against plant models with a true co-simulation that supports the full debugging and analysis capabilities of both tools. Co-code generation is supported as well, enabling combined code for rapid prototyping, HIL testing, and production applications.

Testing a module design with a plant module is easy to do in this environment. Users can model the physical plant in the MBD environment, then design the electronic module in UML. Connecting the module design to the plant model and then testing the module design with accurate plant models assure engineers developing industrial control and automation applications assured that the behavior and functionality of the design is correct before building the actual electronic unit.

A very powerful feature from the MDD/MBD synergy is the ability to integrate detailed mathematical equations generated by a tool such as Simulink into the UML/SysML model, a common demand from engineers designing industrial control and automation designs.

This supports workflows in which systems engineers use MDD to create systems specifications, define the system architecture and high-level behavior and where software developers use MDD to develop their applications while the control engineers use MBD to design the complex control algorithms. This also supports the process when one engineer uses both tools.

MBD/MDD Scenario #1: Stretch Blow Molding Machine Controllers
Working in combined MDD and model based design environment offers a powerful solution, but requires that users adhere to a workflow within the tool environments that allows each to capitalize on its respective strengths. By allocating different functions to each tool, users can benefit form a seamless workflow in their application.

In a recent project where the two tool environments were combined to help develop the control unit system and software for a state-of-the-art stretch blow molding machine, engineers, software developers and controls specialists determined that mapping the project to a clearly defined workflow was critical to the project's success. As the project moved forward, designers determined that the best workflow process was to assign the functionality piece to the MDD environment, and utilize MBD tools to determine performance.

The stretch blow-molding machine was a legacy project that required flexibility for numerous variants, meaning that the control system needed to be flexible enough to operate flawlessly on several different machine configurations.

A sophisticated machine that included not just the molding operation but also post-production loading and other automated features, the stretch blow molding process requires that the plastic is first molded into a "preform" using an injection molding process.

A perform typically resembles a thick-walled test tube, and is produced with the necks of the bottles molded into one end, including the cap threads, typically manufactured from a PET plastic material. The advantage of utilizing this process is that processors obtain a more robust, clear, higher quality finished container that can be filled with pressurized contents like soft drinks—using stretch blow-molding, manufacturers can produce bottles faster than traditional operations, and with this application, in a 'lights out' production facility.

In order to do this, however, the stretch blow-molding machine relied heavily on the controller unit to provide the precision, control, and reliability necessary to obtain repeatable results from the molding operation.

When combining the MDD environment and MBD tool chain for this industrial application, the best practice is to use the MDD environment for requirements analysis and functional analysis of the design. In this case, the blow molding operation was described, the common function traits were determined, and functionality was identified.

Next, the MDD tool was used for functional analysis, whereby the common function traits were grouped into use cases. These use cases were then analyzed in detail, so as to identify the underlying functionality of the system.

Also, the functionality was checked for completeness, correctness, and to assure that the entire system was unambiguous. Specifically for the stretch blow molding machine application, this meant analyzing the separate axis for the system, which included loading, unloading, molding, cutting, démodé and mode, transfer, etc. functions.

Lastly, the MDD environment was used to determine the project's architectural design, using actors in the tool to describe interactions between the functions and utilizing the Harmony SE process. In the architectural design phase, the designers can allocate the identified functionality to the architecture, and check the allocation strategies before implementation into the black box or white box view.

For more detailed design work, engineers turned to the MBD tool. Here, components from the architectural design phase were executed, with an emphasis on developing system control algorithms. From this point, software development was possible, with performance requirements like speed, and other non-linear behavior such as timing analysis performed on the system architectural design with Simulink.

From the outside, this may appear to be a linear step by step process, but the MDD/ MBD tool chain is really an iterative process--meaning that the tools allow engineers to loop back to areas where analysis shows that allocations require a redesign, in either tool environment. As the controller was developed using an MDD and MBD process, the software development utilized the model to form the basis for subsequent software and hardware design and implementation.

Using this process, engineers, developers and controls specialist alike benefit from a MDD/ MBD integration that interacts where differences between requirements and performance appear, thereby finding potential issues early in the design phase and correcting them in the models, driving both productivity and quality in the finished stretch blow molding machine controller unit. With a shared database and sharing of information, plus a strategic modeling function overlap found in the respective tools, the most potent aspects of each were able to combine to form a very powerful industrial automation design environment.

MBD/MDD Scenario #2: multi-axis robotic control system
Another workflow where MDD and MBD tool environments can be used together is in the development and integration of simulation, mathematical algorithms and state based control algorithms. This can be illustrated using an example based upon the development of a single axis of a multi-joint of a robot.

In the first stage of development, control stability analysis is carried out using mathematical models of the motor system (modeled in the Laplace or Z domain) and the control algorithm, typically PID or non-linear adaptive control algorithms (See Figure 1, earlier) for different parts of the motor operating curve.

The natural tool to model these algorithms and analyze them is a MBD tool environment. More advanced algorithms may include stiffness modeling for more precise path planning of flexible robot arms.

The next stage of development is to build the overall control software for the robot, which can be achieved using the MDD environment's typical use cases workflow (such as Add Path Manually, Teach Path etc) to understand and scope behavior, Sequence diagrams, Class and Structure diagrams, with embedded behavior realized by Statecharts. This model can be used to test the interaction of safety features and general control behavior driven by the interfaces.

These models then need to be brought together, partly because the MDD model will be missing some essential features for robot control and partly because engineers will want to simulate and test the integration of the software with a set of motor models.

Currently, support is available to import code from the Simulink MBD tool into the Rhapsody MDD environment. In this particular example there are two places where code generated from the MBD tool needs to be integrated.

The most important place is the integration of mathematically complex control algorithms that depend upon specialized libraries that support specific integration and differentiation algorithms. These need to be embedded directly into the MDD model and will be tightly integrated with the final code. If the robot is very flexible then the stiffness modeling and path planning algorithms may also be modeled in the MBD tool and then integrated into the MDD model.

The benefit of doing this is that developers can test the path planning and control algorithms in a tool, which is natural fit for the MBD tool. Then, engineers can integrate the generated code into a tool, which allows users model specific system behavior in the MDD environment and generate code for the target easily.

The second place where MBD derived code should be integrated is the actual Simulation code that supports the motor and load modeling. This element sits outside the main piece of software as it is modeling the environment, but it integrates with the main code body through set interfaces, i.e. velocity demand, actual angular velocity, actual angular position, these being typical motor control system interfaces.

The benefit gained from doing this is that the software representing the control system can be tested with the Motor model to see if they work correctly. This is carried out on the host, thereby testing interfaces and general behavior.

Finally, the software model is taken from the MDD environment and then placed onto a target processor. This is easily achieved due to the way that code from the MDD environment is structured, having a behavioral layer, and a factory layer that allows integration of the behavior with the specific OS and target.

This coupled with the large number of standard RTOS compilers, operating systems and targets supported by the MDD tool environment means that engineers and developers can benefit from a much faster design cycle.

Conclusion
The benefits achieved from plugging Model-Based Architecture into Model-Driven Development are very powerful. By adding powerful architectural capabilities to Simulink algorithms users can ensure that the algorithms will interact properly with the other elements in the design. Furthermore, it is possible to understand how software design decisions such as scheduling and sequencing will impact the integrity of the algorithms. In addition to creating a combined model that can be executed to ensure proper behavior, the actual production code is tested as a complete system in the software environment.

Working in a MDD / MBD tool environment is a powerful synergy that extends a truly best in class solution to engineers. Complete process coverage from requirements capture, architecture design, logical and mathematical algorithm design implementation and test is achieved with both tools working together.

Dr. Graham Bleakley is a Principal Consultant with Telelogic UK Systems and Software Modeling Business Unit. He is currently working with a number of European Aerospace/Defense companies on projects such as Eurofighter, PAAMS and Meteor, aiding in the definition and application of Model Based design strategies using UML 2.0 and SysML.

Richard Boldt (Rick) is Senior Director of Rhapsody Product Marketing, Telelogic Systems and Software Modeling Business Unit, and has over fifteen years experience in the embedded systems and real-time industries, with more than a decade of experience focused on Model-Driven Development (MDD) and modeling environment technologies.

Dr. Peter Hoffman is is Director and Chief Methodologist for Systems Design at Telelogic, and has 22 years experience in the design and development of complex systems in the Aerospace/Defense industry (Submarines, Tanks, Missiles and Military Aircraft) and the automotive industry.

Other resources on Embedded.com about UML/SysML