In the classic game of Telephone, players whisper a message to one another until it gets to the last person who retells the message. By the time it reaches the last player, the message has usually morphed into something completely different, often with humorous results.
For companies developing embedded systems, poor communication between teams can result in missed requirements and the wrong product for the market, which is no laughing matter. Without collaboration between each phase of development, information can be lost or incorrectly interpreted, often resulting in a product with incorrect or missing functionality.
Using a model driven development approach helps teams break down barriers between development phases and maintain consistency across the product team.
Collaborating to deliver innovation
Innovative products today are increasingly interconnected, instrumented and intelligent, leveraging electronics and software to perform key functionality integrating with mechanical components. Delivering these complex smart products to market requires a multi disciplined team, spanning diverse backgrounds, expertise and culture that must collectively work together to produce a product meeting often vague or misleading requirements.
Consider the development of a robotic surgical system: Surgeons provide the capabilities and medical insight needed for a safe and successful operation in medical terms. A surgeon probably will not understand the nuances of object-oriented programming or the electro-mechanical characteristics of a robot however. Similarly, the engineers will be largely unaware of the details of human physiology.
Yet the doctor and the engineer must be able to collaborate to deliver a safe and effective surgical system. High-level requirements may be obtained through discussions with surgeons to determine the user requirements for the system which could include functional, performance, clinical, safety or other specifications. The engineer must interpret those requirements to design a system that meets those needs.
But how can the engineer really be sure that he or she is producing the correct system and has interpreted the requirements correctly? Typically this is done with a design review with the customer or other stakeholders. However, problems can arise as the developer is often working in code, which may not be understood by the customer who is more familiar with the problem domain.
The developer can produce presentations that convey the content of the code or try to explain the behavior of the code to the customer. This can lead to a myriad of communication problems as the design is translated back to the requirements. Maintaining consistency between the high level and detailed engineering views is a manual and error prone process.
Communicating through modeling
If you want to build a house then you may go to an architect and describe your set of requirements – four bedrooms, two bathrooms, family room, fireplace, etc. If the architect were to come back to you with a thousand page text document describing your house such as “a wall will run 10 feet from the front doors to a set of stairs that will go up to the second floor” then you quickly would be looking for another architect. You expect to see a set of blueprints that show a picture of what your house will look like which provides you with the required overall view of your house.
In a similar fashion, modeling, through the Unified Modeling Language (UML) and the Systems Modeling Language (SysML) provides a set of diagrams with semantic meaning that enable users to communicate the structure and behavior of a design while also maintaining consistency across these views.
Similar to the architectural plans of a house that include a drawing of the electrical wiring, the modeling diagrams can be used to present different levels of detail of the system to facilitate communication with the different interests of the various disciplines involved in a project. For example, use case diagrams may show high level functionality. Class diagrams may show architecture and state diagrams may show detailed modes of operation of a specific class within the design.
Consistency across design views
There is one big difference between UML and SysML diagrams and architectural diagrams for a house. Even though they may represent different levels of abstraction, the UML and SysML diagrams are not just pictures but are both interconnected and cohesive.
A change in a diagram of the model is also reflected in the other diagrams impacted by that change (Figure 1 below ). This enables consistency across the different views of the design. For example, changing the name of a class on one diagram results in the name changing in all other diagrams so all views stay updated with the latest information.
|Figure 1: UML Diagrams depict high level architecture, detailed subsystem structure, and collaboration of system.|
The model can be transformed or “generated” into code for the design that would run on an embedded target. The structure and even behavior of the complete design can be automatically created from the model, if using higher end tools such as IBM Rational Rhapsody.
Effectively the code is nothing more than another view of the same model. The benefit of this is the ability to work in a visual fashion in the model and then automatically delivering consistent production code from the model. Since these transformations are based around a common point — the model — information in each view is maintained improving robustness of the design.
A common problem in many projects is maintaining consistency between code and documentation. Most developers seldom enjoy writing documentation. Fortunately, the model can also be transformed into documentation for the design. Since the model is a common source for the code and documentation, it can help to avoid errors resulting from inconsistencies in the documentation and design.
Executable specification to get it right
Execution is required to be able to validate that functionality is behaving properly. Some model driven development tools on the market provide another level of collaboration by generating a full executable of the design.
During execution model level debugging can be performed showing the current state of state diagrams or creating sequence diagrams showing the interaction between objects (Figure 2 below ). This enables early validation and allows feedback from customers or stakeholders by allowing them to witness the behavior in a more understandable form than code alone. The model can then be elaborated further with more details while continuing to execute to validate behavior.
Additionally, the execution could be done on a host platform even before target hardware is ready and later be retargeted to an embedded board. Much of the functionality in a design is not platform specific and it can already be validated on the host. When hardware becomes available the time can be focused on timing, performance and platform specific issues.
|Figure 2: Model execution with Rational Rhapsody enables early design validation when bugs are less costly to fix|
Delivering with Collaboration
Delivering the complex products driving the high tech world requires collaborative development between many different disciplines across the development lifecycle. Design information needs to be communicated accurately to avoid costly rework or schedule slips.
Development teams use a modeling approach with UML or SysML to convey views of key design information in a form easier for other stakeholders to understand while also maintaining consistency of the information across the various views to produce a more robust design.
A model driven development approach is not just delivering throw away pictures. The diagrams are interconnected and consistent enabling early validation through execution and generation into production software for the embedded device which helps teams meet their ultimate goal: deliver products that meet customer and market requirements.
Paul Urban is Senior Marketing Manager for Systems and Medical Devices for IBM working with major customers worldwide to successfully develop software and systems using state-of-the-art Model Driven Development tools and methodologies. Paul worked for I-Logix/Telelogic for 14 years prior to IBM acquisition, where he focused on consulting, supporting and training customers to using model driven development for developing embedded systems in the medical, aerospace and defence, and automotive industries, including development and delivery of systems with safety critical aspects.