Software for embedded systems has not only to work properly, it mustalso meet tight memory, processor, and storage constraints of a targetplatform. The application has to be properly architected from the startto meet the platform�½s physical and timing constraints, even when theRTOS, processor, memory, and I/O can change several times during thelife of a product.
Model-based design makes it possible to developsource code for multiple compilers, languages, and underlyingplatforms, even different Real-Time Operating Systems, all from acommon design.
By capturing the intended application'sarchitecture in a high level Platform Independent Model (PIM), theresulting application source code becomes a truly sharable entity, notjust across the same application, but many different ones on otherplatforms.
PIM generates sharable components and raises thelevel of abstraction for an application: developers can directlyexecute a model without needing RTOS integration or writing lengthyprograms.
They can validate applications very early in thedevelopment cycle, fixing errors at the design level, instead ofthrough source code inspection and debugging. The proven model isdeployed as an embedded application on any given platform, with themodelling tool used to define platform specificity.
|Figure1: Testing and verification at every stage of analysis and design.|
Practical process frameworks
Common contributions to schedule slips are inaccurate project scoping,underestimating product complexity, and inadequate unit and regressiontesting. Addressing these problems requires building a system graduallywith continual testing during the course of the development process.
Most embedded projects require significant amounts of system modellingand analysis to produce an accurate interpretation of projectrequirements and their unambiguous production into a system model, forthe software engineers to use for application development.
A minor mistake in the systems engineering model will be greatlyexaggerated when implemented in the software design, and detecting theerrors while testing source code requires that all the precedingsoftware layers are fixed before the error is identified in the systemsmodel
Figure 1 above shows a V process that emphasizes testing and verification at everystage of both analysis and design, and pushes software generationfurther downstream in favour of developing more models. Testing isconcurrently and continually performed on the corresponding models,rather than only on the resulting source code.
|Figure2: Sequence diagram of an ignition system|
Figure 2above is a Sequence Diagram, part of a systems engineeringmodel, of a vehicle ignition management system. Animated interactionssummarise the black-box behaviour of the components, and furnish theinstance values of the associated parameters such as, fuel flow rate,the RPM of the freshly started engine, and the ensuing demand for fuel.
This provides a sound basis for system analysiswith both normal and boundary-level operating conditions. In thedetailed design of the ignition sub-system, software designers addbehavioural details (Figure 3 below ),and generate source code.
|Figure3: System details for the fuel tank|
While specifying the system components and black-box behaviour systemengineers also lay the groundwork for software development. When thedetailed behaviour of one of the components, the vehicle fuel tank, waselaborated to a full-scale detailed behaviour, the software engineersadded a path to pump fuel from the tank, based on the demand for fuelgenerated by vehicle's engine management object.
The systems engineers, recognising the requirement,augmented the design added a behavioural path to the diagram, providinga periodic check (through setting timers) of the remaining fuel in thetank and an error flag if the fuel tank is nearing empty.
To collaborate, the system and software specialistsneed a generic syntax to allow them to review and extend the other'sdesign. This level of detailed behaviour is normally implemented insource code, but systems engineers may not be familiar with theprogramming language, or may be intimidated by its detail. Ahigh-level, Platform Independent syntax, lets both teams delve into thedeepest levels of design detail.
The system detail in Figure 3 is sufficient to generate working sourcecode for the fuel tank. Platform specificity can be added to themodelling tool either as an adaptation layer or directly into themodelled system's diagram, for the software engineer to form a PlatformSpecific Model(PSM) and develop code for the specific target platform.The software engineering team can generate and tailor source code whichoptimally executes on the platform, knowing that the application itselfremains correct and robust.
Changes in platform specifics and architecture aredealt with by generating a new PSM, instead of modifying code andrisking inefficiencies and bugs.
Platform Independent Modelling allows the application's architecture tobe developed and validated independently of the development ofapplication code. The software development team can then focus ondeveloping optimised source code for the selected target architectures,with the knowledge that the application is working and tested. In thisway, organizations get the best of both worlds�½a device that fullyaddresses and meets the requirements of a working application coupledwith an efficient implementation.
IrvBadr is Senior Product Marketing Manager at Telelogic/IBMwith 20 years of development experience in embedded and modelingindustries.
Other resources on Embedded.com about systemmodelling :
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?