George Novacek (Canada)
Circuit Cellar
This article takes a serious look at software engineering and programming. Topics such as automatic code generators, simulation programs, and testing are covered.
Most engineering disciplines started as an art. Gifted people developed a skill, often with barely enough understanding of its underlying principles, and practiced it successfully. Manufacturing steel is a good example. Early on, only a few highly paid artisans knew how to make it. But later, in the mid 19th century, the invention of the Bessemer process put steel manufacturing on a scientific basis. The skilled artisans were no longer needed and the price of steel plummeted.
Software development has followed a similar path. Originally the domain of a handful of gurus, it is becoming a scientifically well- defined activity that, ultimately, management would love to see performed by those proverbial trained monkeys.
People producing software generally fall into two categories. Software engineers are the creators, the people who find solutions, invent new algorithms and, in short, are the drivers of the industry. Programmers are the workers who implement engineers’ ideas given to them in pseudocode, flowcharts, or other methods. They do the hard work of turning ideas into code. But this doesn’t mean the engineer and the programmer can’t be the same person. In small companies, they often are.
While it doesn’t seem that science will successfully automate creative engineering processes any time soon (there have been attempts), in software development, the science is already making great strides by taking over mundane, repetitive tasks, such as source-code generation, version control, traceability, and testing.
AUTOMATIC CODE GENERATORS
Automatic code generators, albeit not very sophisticated, have been with us for a long time. In the mid-1990s I purchased a fuzzy logic design suite. I never used it, because customers shuddered at the word “fuzzy” and insisted on our time-proven technique of gain scheduling. Recently, I discovered the suite in a drawer and decided to try it. I was surprised to see that the code it generated was essentially what we did for gain scheduling, with one significant difference. Using the suite’s graphic interface made the development much faster.
Since those early days, automatic code generators have come a long way. A good example of a modern automatic code generator I’m familiar with is the SCADE (an acronym for Safety and mission Critical Application Development Environment) Suite, a suite developed by Esterel Technologies. Unlike most other similar programs, it has been officially qualified for the development of safety-critical applications up to and including Level A, as per the DO-178B software standard. SCADE has been used by companies developing applications for industries including automotive, rail, communications, aerospace, medical, and military. A few examples are Dassault, Audi, Boeing, Lockheed, Siemens, and Airbus.
To appreciate how SCADE works, let’s consider the development of an aircraft landing gear control system. The system engineers specify what is needed for its control in a System Requirements document. After the system requirements decomposition, where hardware and software requirements are defined for the embedded controller, the software engineer is given a Software Requirements document. Let’s look at two specific functions contained in this document: the closed-loop control of the nosewheel angle and sequencing of the extension and retraction of the landing gear.
From the System Requirements document, the system engineer obtains the basic gains and limits for the nose- wheel control and includes them in the Software Requirements document. The software engineer develops a block diagram of the software architecture, which is then simulated and tweaked, and the gains are modified, typically using Simulink from the MathWorks (or some other simulation program) until the simulated performance of the closed loop is compliant with the spec. The resulting block diagram is shown in Figure 1. The graphical rendering of the closed-loop control in Figure 1 becomes a part of the Software Design Description document.
 |
|
| Figure 1. | Closed-loop block diagram. |
Sequencing of the main landing gears is determined by a state machine. Just as with the closed-loop control, the engineer develops the state machine block diagram, which is also simulated until a satisfactory result is obtained. This is also rendered graphically, as shown in Figure 2, and it becomes a part of the Software Design Description document.
 |
|
| Figure 2. | State machine graphical interface. |
The Software Design Description document goes to a programmer to develop the source code. When it comes to modules such as the closed-loop control or the landing gear state machine shown in Figures 1 and 2, the design is fed through a graphical interface into the SCADE suite. The SCADE suite in turn generates the source code, which is then integrated into the entire embedded system firmware, usually as function calls. During hardware/software integration, some parameters may need to be adjusted, as they are affected by the accuracy of mathematical models for simulation.
CONFIGURATION CONTROL PROGRAMS
Version control is a crucial function during any development. There is nothing worse than a software team working on different versions of documents or source code. There were times when one of my suppliers kept updating a buggy Assembler without bothering to bump up the version number or even include the file modification date. Since every Assembler/compiler version change requires retesting of critical software, keeping track of the Assembler version was a nightmare. I also witnessed an aerospace manufacturer losing configuration control due to carelessness. The repercussions were disastrous. The certificating agency forced the manufacturer to scrap several months of development work and to go back to the last verified configuration.
Such occurrences can be prevented if the developer uses a configuration control program. Among the best known is IBM’s Rational DOORS, which stands for dynamic objectoriented requirement system. DOORS is a database that keeps track of multiple users opening and modifying multiple documents or source codes and updates the version number accordingly.
TESTING, VERIFICATION, & VALIDATION
Another mundane, critical, and time-consuming task left to programmers is the process of testing, verification, and validation. Let’s review each one.
Testing is a generic term meaning module testing, module integration, hardware/software integration, and so forth, simply ensuring that the code works as designed.
Verification is, to a large degree, a bureaucratic task. It ensures all specification requirements have been met and can be traced through documentation down to the source code, and every line of the source code has a corresponding requirement in the specification. It ascertains proper stack usage, data typing, worst-case timing, interrupt-conflict avoidance, range violation, and so forth.
Verification can be performed on a host computer (e.g., a PC) or the target system. Using a host computer is often more convenient. The verification can be concurrently performed by a number of programmers without incurring the cost of several target systems.
Verification has also been automated to a large degree. Polyspace from MathWorks is one of several programs alleviating the mundane tasks from the programmers’ shoulders. Software verification is too large a subject to address here. I will take a closer look at this process in a future column.
Finally, validation is performed on the target system, to ensure the entire system works as expected. Here is when “the rubber meets the road” literally, and top-level specification errors may be discovered. Systems comprising mechanical and electrical parts are notorious for not behaving exactly as simulated. This is mainly because the mathematical models can’t take into account all the variables, especially those of mechanical parts. In a well-designed system, the necessary changes can usually be confined to modifications of gains and limits. It is a good idea in an embedded software design to keep all values that could potentially need adjustment in a password-protected table, accessible and modifiable through a PC interface, such as USB.
Today, there are many tools available to software developers. Here, I only mentioned a few. I also want to allay software developers’ fears of losing their jobs to trained monkeys. That is not yet on the horizon. In the meantime, the science will continue to make our lives easier and our products much less prone to human error.
