Combining Model-Driven and Model-Based Design in industrial and machine control - Embedded.com

Combining Model-Driven and Model-Based Design in industrial and machine control

Developing complex systems and software for embedded or real-timeindustrial automation applications is a daunting challenge fordesigners and engineers. Projects require that engineers, developersand controls specialists maintain high quality systems and software,meet demanding schedules and managing complexity, while simultaneouslyfulfilling safety, accuracy, clarity, traceability and productivityobjectives.

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

Combining environments, however, can be a powerful strategy to solvethe quandary. Ideally, this approach allows users to harness the bestaspects of each tool to create a better solution by combining the powerof the tools to create an environment that is collectively better thanthey would be individually.

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

Table1. MDD versus MBD feature comparison

By combining these best-of-breed solutions, users benefit from anenvironment that covers the complete process, from requirements tospecification, design, development, implementation and test. Notablyfor industrialautomation projects like robotics or stretch blow moldingtechnologies (Figure 1, below ),as well as aerospace/ defense and automotiveapplications , engineers that realize the full potential of theMDD/ MBD approach are able to develop robust systems and software in aneasy-to-use modeling environment for better overall quality and meetrapid time-to-market goals.

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

Complementary Solution
Most developers have strong preferences about the modeling tools thatthey use to design new projects. With the days of static paper designslong gone, choosing tools that enhance the workflow, boost productivityand are cost effective are very important organizationalconsiderations.

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

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

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

MDD and MBD: The Power of Two
The MDD/ MBD combination is powerful because it offers a completeprocess coverage solution while allowing users to select the tool mostappropriate for each activity in the design cycle. With MDD, users canaccess requirements capture and analyze functions, define systems andsoftware architecture and develop logical algorithms. Each function canbe simulated and tested to ensure that they are correct; customizeddocumentation can be generated for enhanced communication and theactual implementation can be realized through production codegeneration.

With MBD, users can create plant models that define the dynamicbehavior of the physical elements that the system will interact withand develop the mathematical algorithms that control these plantmodels. This can all be simulated in MBD to ensure proper results, codecan be generated from the control algorithms for use in prototyping andproduction while code can be generated from the plant models to be usedin hardware-in-the-loop(HIL) testing. 

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

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

This includes identifying requirements that are not yet addressed,finding design elements not justified by a requirement, easily findingall design elements impacted by a requirement change providing the truecost of that change and ultimately understand what requirements may beimpacted by a design change to ensure that by fixing one thing othersare not broken.

Figure2: Rhapsody Gateway view of a requirement captured in DOORS that hasbeen linked to both Rhapsody and Simulink model elements.

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

The natural workflow of the Simulink user is preserved, with theability to access Rhapsody as a block in the Simulink model, enablingengineers to model the architecture, behavior and logic of blocksrepresenting electronic or embedded systems using a full UML / SysMLenvironment. Additionally, UML/SysML-based MDD designs can be testedagainst plant models with a true co-simulation that supports the fulldebugging and analysis capabilities of both tools. Co-code generationis supported as well, enabling combined code for rapid prototyping, HILtesting, and production applications.

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

A very powerful feature from the MDD/MBD synergy is the ability tointegrate detailed mathematical equations generated by a tool such asSimulink into the UML/SysML model, a common demand from engineersdesigning industrial control and automation designs.

This supports workflows in which systems engineers use MDD to createsystems specifications, define the system architecture and high-levelbehavior and where software developers use MDD to develop theirapplications while the control engineers use MBD to design the complexcontrol algorithms. This also supports the process when one engineeruses both tools.

MBD/MDD Scenario #1: Stretch BlowMolding Machine Controllers
Working in combined MDD and model based design environment offers apowerful solution, but requires that users adhere to a workflow withinthe tool environments that allows each to capitalize on its respectivestrengths. By allocating different functions to each tool, users canbenefit form a seamless workflow in their application.

In a recent project where the two tool environments were combined tohelp develop the control unit system and software for astate-of-the-art stretch blow molding machine, engineers, softwaredevelopers and controls specialists determined that mapping the projectto a clearly defined workflow was critical to the project's success. Asthe project moved forward, designers determined that the best workflowprocess 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 requiredflexibility for numerous variants, meaning that the control systemneeded to be flexible enough to operate flawlessly on several differentmachine configurations.

A sophisticated machine that included not just the molding operationbut also post-production loading and other automated features, thestretch blow molding process requires that the plastic is first moldedinto a “preform” using an injection molding process.

A perform typically resembles a thick-walled test tube, and isproduced with the necks of the bottles molded into one end, includingthe cap threads, typically manufactured from a PET plastic material.The advantage of utilizing this process is that processors obtain amore robust, clear, higher quality finished container that can befilled with pressurized contents like soft drinks—using stretchblow-molding, manufacturers can produce bottles faster than traditionaloperations, and with this application, in a 'lights out' productionfacility.

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

When combining the MDD environment and MBD tool chain for thisindustrial application, the best practice is to use the MDD environmentfor requirements analysis and functional analysis of the design. Inthis case, the blow molding operation was described, the commonfunction traits were determined, and functionality was identified.

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

Also, the functionality was checked for completeness, correctness,and to assure that the entire system was unambiguous. Specifically forthe stretch blow molding machine application, this meant analyzing theseparate 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'sarchitectural design, using actors in the tool to describe interactionsbetween the functions and utilizing the Harmony SE process. In thearchitectural design phase, the designers can allocate the identifiedfunctionality to the architecture, and check the allocation strategiesbefore 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 thispoint, software development was possible, with performance requirementslike speed, and other non-linear behavior such as timing analysisperformed on the system architectural design with Simulink.

From the outside, this may appear to be a linear step by stepprocess, but the MDD/ MBD tool chain is really an iterativeprocess–meaning that the tools allow engineers to loop back to areaswhere analysis shows that allocations require a redesign, in eithertool environment. As the controller was developed using an MDD and MBDprocess, the software development utilized the model to form the basisfor subsequent software and hardware design and implementation.

Using this process, engineers, developers and controls specialistalike benefit from a MDD/ MBD integration that interacts wheredifferences between requirements and performance appear, therebyfinding potential issues early in the design phase and correcting themin the models, driving both productivity and quality in the finishedstretch blow molding machine controller unit. With a shared databaseand sharing of information, plus a strategic modeling function overlapfound in the respective tools, the most potent aspects of each wereable to combine to form a very powerful industrial automation designenvironment.

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

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

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

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

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

Currently, support is available to import code from the Simulink MBDtool into the Rhapsody MDD environment. In this particular examplethere are two places where code generated from the MBD tool needs to beintegrated.

The most important place is the integration of mathematicallycomplex control algorithms that depend upon specialized libraries thatsupport specific integration and differentiation algorithms. These needto be embedded directly into the MDD model and will be tightlyintegrated with the final code. If the robot is very flexible then thestiffness modeling and path planning algorithms may also be modeled inthe MBD tool and then integrated into the MDD model.

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

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

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

Finally, the software model is taken from the MDD environment andthen placed onto a target processor. This is easily achieved due to theway that code from the MDD environment is structured, having abehavioral layer, and a factory layer that allows integration of thebehavior 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 environmentmeans that engineers and developers can benefit from a much fasterdesign cycle.

Conclusion
The benefits achieved from plugging Model-Based Architecture intoModel-Driven Development are very powerful. By adding powerfularchitectural capabilities to Simulink algorithms users can ensure thatthe algorithms will interact properly with the other elements in thedesign. Furthermore, it is possible to understand how software designdecisions such as scheduling and sequencing will impact the integrityof the algorithms. In addition to creating a combined model that can beexecuted to ensure proper behavior, the actual production code istested as a complete system in the software environment.

Working in a MDD / MBD tool environment is a powerful synergy thatextends a truly best in class solution to engineers. Complete processcoverage from requirements capture, architecture design, logical andmathematical algorithm design implementation and test is achieved withboth tools working together.

Dr. Graham Bleakley is a PrincipalConsultant with Telelogic UKSystems and Software Modeling Business Unit. He is currently workingwith a number of European Aerospace/Defense companies on projects suchas Eurofighter, PAAMS and Meteor, aiding in the definition andapplication of Model Based design strategies using UML 2.0 and SysML.

Richard Boldt (Rick) is Senior Directorof Rhapsody Product Marketing, Telelogic Systems and Software ModelingBusiness Unit, and has over fifteen years experience in the embeddedsystems and real-time industries, with more than a decade of experiencefocused on Model-Driven Development (MDD) and modeling environmenttechnologies.

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

Other resources onEmbedded.com about UML/SysML

1) Needfor modeling tools rises with design complexity
2) In Focus: Unified Modeling Language
3) Introduction to UML statecharts
4) UML evolves total system perspective
5) Introduction to UML Class Diagrams
6) State machine shortcuts
7)From UML to embedded system: Is it possible?
8)  Howto use UML in your  SoC Hardware/software design

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.