Modeling embedded systems - Part 3: Where to model
Operational complexity
Complexity can also be operational, as in the case of Agworks, Inc (Ontario, Canada). They needed to develop an embedded control system capable of automating a large soybean processing plant with multiple concurrent processes and provide a software architecture that was both scalable and maintainable.
Developing and integrating a state-based application with so many concurrent processes presented a unique challenge. Because much of their equipment is not directly viewable, developers had to rely on development tools to aid in the integration and debugging of the code.
A statechart implementation (Figure 18) was ideal for this application. During the design phase, the abstraction provided by the NI LabVIEW Statechart Module made it much easier to visualize how all the separate processes would work together. The self-documenting nature of statechart diagrams also saved valuable time during the design phase of the project.
Click on image to enlarge.
Figure 18 - The abstraction that the statechart software provided made it much easier to visualize how the complex network of systems would work together.
As development progressed, extensive use of the statechart tool helped keep the code organized and readable. When integration began, the utility for debugging the statecharts was crucial. With highlight execution enabled, the developers were able to monitor many concurrent processes closely. They could tell exactly when a transition was triggered and exactly which state it went into. This saved a great deal of time during the debugging process.
After several months of operation, Agworks needed some additional features. The upfront software design, modeling, and documentation made a complex application much easier to understand and much faster to learn.
The statechart diagrams provided a clear overall picture of the embedded system. Not only was it clear, but the statechart in this complex situation was also effective in explaining the architecture and self-documenting, demonstrated by the fact that the new developer on the Agworks team was able to get up to speed quickly with this large project and edit the application, adding capabilities to satisfy the customer’s request.
For these types of complex applications, using the right software tool and modeling approach can be beneficial in every step of the development life cycle, and continue to benefit you and your customers throughout the lifecycle of the product.
Cost of defect versus when detected
Ensuring you employ proper modeling and simulation techniques isn’t just about getting a better design; it is also about cost savings and getting it right sooner. After an analysis of more than 60 software development projects (http://www.irma-international.org/proceeding-paper/gathering-user-needs/32282/ ) at companies such as IBM, GTE, and TRW, we can clearly see the cost of finding a problem early in the process is far less expensive (Figure 19).
Click on image to enlarge.
Figure 19 - The cost of a defect is significantly impacted by when the defect is found.
Modeling combined with software engineering best practices will help address most if not all of the common pitfalls in poor embedded system design programming.
Figure 20 is a simple way of viewing the software engineering process. It reflects what is typically referred to as the waterfall method of development. While great in principle, most software engineers accept that the waterfall method is impractical and that reality requires significant overlap between these various phases. In other words, it’s almost impossible to avoid changes to requirements later in development.
The key is to have tools and practices to mitigate the risks caused by these last minute changes and to understand how these changes will impact other aspects of your application. You can apply software engineering and modeling techniques throughout this development.
Large development teams require modeling
Even though the modern trend is to create small, agile development teams, we know that certain complex embedded projects require larger teams. Large teams suffer from a few critical challenges, such as communication challenges, geographic and language distribution, and tool differences. Modeling can help address some of these issues.
First, and perhaps the most impactful, modeling can facilitate clear communication among different teams on one embedded project. Project requirements can only look to serve as a project calibration device to a point, and then the engineers must get into the actual application. If the team can design a useful system model, it is a dynamic, accurate representation of the project that can ease cross-team communication.
Related, this type of project communication can easily span multiple speaking languages as well as geographic locations. Instead of relying on either written documentation that would need to be translated, an embedded model can be the consistent ‘voice’ of the project. While physical prototypes are capable of demonstrating the concepts and goals of a project, they are limited to being in a single geography.
When you have a large team you are also bound to have developers with differing tool preferences. This means you need to keep your model in software that can be shared between tools – something open and viewable by anyone on the team.
Just employing modeling doesn’t solve large development team issues, you still must develop readable (and therefore maintainable) code, document your code, employ source code control and change management, utilize unit testing, and get as much standardization and code reuse as possible.
Part 1: Why model?
Part 2: Modeling examples
Part 4: If prototypes aren't possible
Shelley Gretlein is the Director of Software Product Marketing at National Instruments. Currently focused on growing the application and success of graphical system design globally, Gretlein is responsible for the development strategy and worldwide evangelism of the LabVIEW software platform including LabVIEW Real-Time and LabVIEW FPGA. She joined National Instruments in 2000 and holds a bachelor’s degree in computer science and management systems as well as minors in Mathematics and French from the Missouri University of Science and Technology.
This article is based on material by Shelley Gretlein written for inclusion in “Software Engineering for embedded systems,” edited by Robert Oshana and Mark Kraeling, to be published early in 2013 by Morgan Kaufmann, a division of Elsevier, Copyright 2013. For more information about “Software engineering for embedded systems” and other similar books, visit www.elsevierdirect.com.
Loading comments... Write a comment