Managing embedded systems complexity with SysML - Embedded.com

Managing embedded systems complexity with SysML

Today's embedded devices can many times be considered as fullyfunctioning, albeit resource-limited, systems. To achieve goals oflow-cost and small footprint, resources like processor power, memorysize, and power draw must be kept as small as possible. These resourcesmust satisfy the device's specific application and cannot be wasted byclumsy implementations, or by inefficient integration into the largersystems to which they often belong.

Software engineers can be very effective at optimizing their codefor their device's specific function, but usually do not or cannotoptimize the overall system integration.

It is often the aspects of the final systems integration that causeapplications to exceed their allocated resources, forcing costly anddifficult decisions to be made in optimizing and modifying theapplication. Since this usually happens at the end of the developmentlifecycle, many embedded devices miss their committed delivery dates orare even scrapped altogether.

Model-driven development overcomes many of these issues by makingsuccessful systems development the primary effort and component designa resultant function.

The latest generation of model-based development languages providesa way to manage complexity issues of this type. The standards-based UML2.0 and SysML languages allow companies to apply the principles ofModel-Driven Development to focus development efforts while expandingoverall vision and creativity.

They allow otherwise disparate teams to function as integratedunits, with planners, designers, developers, and testers working sideby side during the development process; increasing collaboration andavoiding last-minute surprises.

UML 2.0
The Unified Modeling Language (UML) was initially conceived as a way tovisually solve software design and development problems. The ObjectManagement Group's UML version 2.0 furthers the initial design byhelping specify, visualize, and document models of software systems,including their structure and design.

Users can analyze their future application's requirements and designa solution that meets them, representing the results using some or allof UML 2.0's thirteen standard diagram types. Software teams can usethe standards-based approach to visualize and construct their projectsin an orderly and consistent manner.

Integrated code generation allows the resulting models to betranslated into the development teams programming language, be it C,C++, Java, or something else, and be treated the same as code from anyother source.

SysML
The Systems Modeling Language, also known as SysML, is an optimizednotation for Systems Engineers, which was designed by Systems Engineersand supports the creation of accurate, successful systemimplementations. A system refers to an often complex interaction ofindividual application components which function together for a definedset of purposes and goals. The symbiotic inner workings of a mobilephone comprise a system, as does the entire wireless telephone network(which can also be referred to as a “system of systems”).

SysML is a visual modeling language standard for the specification,analysis, design, verification, and validation of systems that mayinclude hardware, data, personnel, procedures, and facilities, as wellas software. Designed by systems engineers for system engineers, SysMLis an extension of UML 2.0 and is implemented as a UML 2.0 profile.

SysML was created to improve communications across the systemdevelopment lifecycle, enhance knowledge capture, increase re-use ofdesigns, permit early verification of designs, and lower maintenancecosts.

Systems engineers have used models for decades to analyzerequirements, perform high level design, and assess and verify designsalternatives. Up until now, this modeling was done using many differentnotations, each with their own supporting tools. This has led to poortraceability, information transcription errors between tools, anddifficulties maintaining consistency between the disconnected models.

By providing a unified modeling notation and associated toolsupport, SysML will enable true model-based design leading toconsistent, unambiguous designs and specifications. Model consistencycan be automated (e.g., change propagation if an interface changes) andchecked during design and maintenance. Tools can further increasequality and reduce risk by enabling simulation and execution of themodels to verify that they satisfy the requirements.

Since SysML is based upon UML 2.0, the same model that specifies thefunctioning system can be used to create and define the specificationand initial starting point for those parts of the system allocated toindividual components and their software; extending the model-drivennature of the development process. This further reduces errors andmaintenance costs by bridging the gaps between systems and softwareengineering.

Model-Driven Development
The application of UML 2.0 and SysML to the domain of designing complexproducts is known as Model-Driven Development (MDD). MDD supports aniterative, top-down development process which ensures that the bigpicture is clearly defined and understood, before the focus shifts tothe details.

A common misconception of MDD is that it in some way displacessystems and software engineers. This is simply not true. MDD enhancesthe engineers' abilities by letting them focus on the creative aspectsof systems and software development, optimization, and tuning; whilemaintaining the ability to iteratively and interactively simulate,test, and compare their results along the way. The developer has afully-defined set of interfaces to which he or she can plug-in and testtheir efforts, as well as to aid the eventual integration of specificcomponents back into the overall system.

A model-driven approach allows the project to be partitioned andreassembled in multiple scenarios. Test development occurs in parallel,providing test teams the ability to fully understand the applicationand its functions the moment they begin work.

Modeling a missile fire controlsystem
A good example of the effectiveness of MDD is to look at how SysML (andUML 2.0) would be applied to a typical system consisting of embeddeddevices, in this case the Missile Fire Control System for a US Armyportable missile launcher.

The problem is derived from a Department of Defense analysis whichindicated the need to increase the target detection range withoutsacrificing missile speed, accuracy, or lethal impact. To keep ourexample as simple as possible, only a small subset of the functionalityand associated system requirements and design are addressed tohighlight this application.

Using our modeling notation, the overall system design is consideredlong before individual component platforms need be specified. However,the system retains the flexibility to immediately include pre-specifiedcomponents required (or considered) for incorporation, thus eliminatingpotential conflicts later in the design process.

The system can be tested as an integral whole—long before thespecific components are fully specified or designed. SysML providesmany systems engineering-specific diagrams to model requirements, usecases, behavior, activity, architecture, interfaces, and performance,which allow the system, in this case a complicated battlefield controlsystem, to be thoroughly designed, simulated, tested, andde-constructed for detailed component and subsystem design anddevelopment.

Once the system is verified, individual subsystems and componentscan be doled out to project teams, subcontractors, and make/buyevaluators, providing all teams the detailed presentation ofrequirements they need to design and test against. In addition to thecomponent specifications and high-level design, pre-defined tests forboth the models and the resulting technology are included, allowingtest development to be done in full synchronization with subsystem andcomponent design.

Throughout the systems design lifecycle, SysML allows the systemengineers to perform x essential functions: determine systemeffectiveness; derive, verify and trace requirements; define systemuses cases to analyze and specify features and define overall componentmakeup, including internal and external interfaces; assess performance;provide blueprints; generate target code and tests.

Determine system effectiveness
System design is often a matter of give and take. Given a set ofrequirements, the choice is between satisfying all requirements andmaking trade-offs to arrive at an optimal design.

For example, maximizing the detection range of the missile radarsystem will contribute to enhanced performance at the cost of potentialmissile accuracy and speed of delivery. SysML can be used to create aset of “Measures of Effectiveness”, which represent the criteria bywhich alternative designs or architectures are assessed and associatethem with key performance parameters that determine the resultingeffectiveness.

Derive, verify, and tracerequirements
Following engineering analysis of the user requirements a set of systemrequirements is derived (Figure 1 below ).For example, these could consist of Targeting Accuracy, Time to AcquireTarget, Effective Range, Warhead Impact Zone, and Missile Speed.

Figure1. Requirements Diagram

The systems engineer can then utilize these depictions for differingrequirements-based studies of various system and subsystem components.The Targeting system requirement can be derived from the TargetingAccuracy, Time to Acquire Target, Warhead Impact Zone, and EffectiveRange user requirements.

The Time to Destroy Target requirement is derived from Time toAcquire Target and Missile Speed user requirements. The modeledrequirements can then be verified for completeness and accuracy, aswell as to show complete traceability from the user requirementsthrough derived system requirements to detailed behaviorspecifications.

Define use cases to analyze andspecify features
SysML lets the system designer fully depict the Missile Fire Controluser scenario. The missile launcher and other active players (the FireControl Officer, maintenance, Battlefield Command, etc.) can be shownas they interact with the system to determine scenario-based systembehavior and responsiveness, while providing traceability to thedriving requirements.

Resultant dynamic behavior from imposed actions can also be modeled,such as describing the dynamic behavior of the Radar Controller for theactivity “seek” and showing how this behavior interrelates with thesystem in its entirety. Define overall component makeup
SysML can be used to depict the equipment breakdown structure of theFire Control system (Figure 2 below ),with external and internal views of component and subsysteminteraction.

Figure2: Equipment Breakdown Structure

The missile launcher would have a radar subsystem, an antennasubsystem, a launch control subsystem, a launch mechanism, and achassis subsystem, each consisting of components like radar, missiletube, operator console, antenna controller, etc.

Additional subsystems, such as diagnostics monitoring orfriend-or-foe detection systems, can be easily added to the diagram asrequired, even if only to simulate the effects of adding a capabilityto the system design. Within the system, individual subsystems andcomponents can be described, as well as their interactions with thesystem.

For instance, each of the parts of the Antenna Subsystem can bedepicted in the diagram along with the interconnections between parts.System interfaces are also shown, such as for the command input andvisual display interfaces of the Operator Console Subsystem and theflow properties (matter, data, energy) within the interfaces.

Assess performance
Such analysis includes such things as a roll-up of technicalperformance measures that relate the overall resulting weightingfactors of the subsystem components to their individual functionality.

Each item can be “weighted” according to its relative importance forthe functionality being considered. In this case the total effectivekill zone of the warhead, the accuracy of the targeting system, thetime to acquire and lock on target, the actual air speed of themissile, the effective range of the missile, and the mobility factorsof a specified target can be individually weighted and compared toensure that the entire system yields the desired level of weaponeffectiveness.

Increasing or decreasing any one of the parameters' values (such asvarying the air speed of the missile) can be measured as to its overallimpact on mission success.

Provide blueprints forcomponent/software development
Each subsystem and component can be used as the basis for specificdesign efforts. Hardware engineers can utilize the model as aspecification blueprint upon which their designs are based. Softwaredevelopers use the models in a similar fashion, but can furtherelaborate the model in order to define target software.

UML diagrams are used to describe the parameters of the targetplatforms and the functionality, behavior, and constraints of theresulting application.

Functional, unit, and other tests can be simultaneously defined, toensure that modifications to the component will be reflected in allassociated tests. In the Missile Launch Controller, the AntennaController could be defined with a platform consisting of a 32-bitprocessor, a defined amount of RAM and ROM, a specified RTOS, and allrelevant interfaces (I/O).

Generate target code and tests
Source code generators are used to provide software for the componentprocessor. Already supported in select UML products, the OMG issettling on a specification for UML-based source code generation.

Called Executable UML (xUML), the intent is to allow the desiredsoftware behavior to be included in the component model, allowing forthe generation of relevant and accurate target source code.

In our example, the platform for the Antenna Controller could beprogrammed with C code, which will be optimized to perform under tighttime and memory constraints. Because the entire system was thoroughlytested at the model level, robust and accurate code is generated,resulting in minimal hand-tuning and debugging.

Legacy software code can be “reverse-engineered” into model form forintegration and testing with the entire application, once againassuring minimal time spent on labor-intensive code manipulation bysoftware engineers.

Once designed, the Antenna Controller can be virtually plugged backinto the system model, allowing it to be iteratively tested against theentire system throughout the development process.

Complete unit tests can be automatically generated for testengineering teams. Resulting modifications to the software code andapplication can be applied at the software or model level, providingcomplete flexibility in achieving reliable and understood results,greatly enhancing time to market.

Conclusion
Systems engineering is an established discipline within the frameworkof complex design and development. Rather than attempting to recreate amethodology, SysML was developed as a model-based notation to suitsystems engineers in a familiar manner, while increasing theirefficiency and effectiveness. These benefits are further leveraged fordesign, development, and test of embedded systems.

The principles of model-based development using standardizedlanguages such as UML 2.0 or SysML foster a clear focus of alldevelopment activities while increasing transparency and visibility ofthe system under development. The creativity of the development teamcan be fully dedicated to its primary tasks, which are tackled as ateam.

Products like Telelogic TAU G2 fully offer a robust,high-performance design and implementation environment based on dynamicand executable models, helping engineers to leverage the full potentialof SysML and UML 2.0 technologies.

Scott McKorkle is the Director of Product Marketing for theTAU product line at TelelogicAB and a 23-year veteran in the real-time and embedded market.

Leave a Reply

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