The shift from 8 or 16 bit to 32 or 64 bit Digital Signal Processor (DSP) chip technologies creates an opportunity for next-generation device development. Just a few years ago, controller boards required both DSPs and traditional CPUs to perform the application processing and the signal processing.

Today, inexpensive DSPs perform their traditional signal processing functions, but their added processing power and low cost make them ideal candidates for performing both functions. Companies that are able to leverage the "free" power from new 32 and 64 bit DSP chips to host new applications stand to gain a competitive advantage.

To do this, organizations must move beyond firmware to software, meet aggressive time-to-market goals, and develop high quality applications. Organizations that embrace an embedded systems and software process that allows them to design, validate, simulate, test and collaborate on applications in one powerful design environment have a clear advantage over their competition.

Model Driven Development (MDD) solves these issues; modeling enables software reuse, allows distributed teams to easily collaborate and build system-wide models that encompass the entire design in one cohesive environment. Using MDD, teams can model the whole system, re-using their existing software, leveraging distributed teams to their fullest advantage and moving DSP chip design from firmware to software — thereby expanding the DSP chip's role in embedded applications.

This paper discusses how a drilling products manufacturer for the oil and gas industry leveraged MDD to build their latest set of downhole sensors. By embracing a new workflow, MDD reduced the time required to build DSP based applications, improved application quality and helped the company establish a competitive edge in the marketplace.

The Downhole Application Challenge
An oilfield drilling products manufacturer based in Houston, Texas, began development on a new suite of downhole sensors. Downhole sensors detect the presence of oil and natural gas in or near the borehole while the well is being drilled. The sensors attach to the drill rig to monitor the rock formation, the mud, and the borehole itself. DSPs control all of the downhole sensors and perform all of the real-time downhole processing.

Historically, every time the company upgraded sensor hardware, improved an algorithm, or used a different DSP, the firmware crew assigned to the sensor had to re-develop the entire application. Each team implemented its application independently of the other sensor teams.

The firmware teams noticed that they could abstract common functions, such as collecting and logging data, communicating with other modules and the surface, and reading analog and discrete sensors. By abstracting these functions, all of the sensor teams could use the common code.

The problem that the sensor teams faced was how to represent the firmware design. They chose a Unified Modeling Language (UML)-based approach because their research indicated that UML would provide better visibility into their designs. But they needed more than just a way to represent their firmware " they needed a new firmware development process.

As the company developed its vision, they crafted a solution set "wish list" that included the ability to: Create new software designs in a standard modeling language
Map requirements to functionality for the easy organization of reusable elements
Reuse common functions easily across product development
Generate code directly from the design model
Simulate and test designs early in the process

The software development process that they found best met their vision and was ideal for embedded applications was the Telelogic Rhapsody MDD solution. Like many processes, MDD uses UML to represent the firmware design, but MDD includes all of the firmware development lifecycle steps.

Following MDD, architects capture, elaboration, and trace requirements directly in the model. Developers design, implement, and unit test the code directly in the model and Testers build test cases directly from the model.

Driving Results Using Requirements Analysis
Like many commercial ventures, the team's requirements came from a variety of sources; marketing knew what new features the customers wanted, the scientists knew what new algorithms they wanted to try, electrical engineering knew what chip sets will survive in the environment, and program management knew the schedule and budget. Like many ventures, these groups had a history of creeping (and sometimes completely changing) requirements throughout a program.

As part of their transition to MDD, the firmware leads changed the way they gathered requirements. Previously, they pulled requirements from a combination of text statements in a product description document and group mythology. The requirements were never fully captured or confirmed by the stakeholders. Furthermore, they could not trace designs and tests back to the requirements.

On this program, the sensor teams started gathering requirements by capturing the product requirements directly in the product description document, just as they had on previous projects. This time, however, they exported the requirements to a UML model.

The Workflow
The teams began by defining a new workflow that would help them meet their overall product goals. In the model, they decomposed and refined the requirements by creating use cases, that is, named system capabilities. The team traced these use cases to the product requirements, enabling them to map system capabilities to the product requirements.

Use cases contain scenarios that explain, step-by-step, what the hardware and firmware must do to successfully meet the capability's goal. In addition, some scenarios describe how the system responds to exception conditions. The team described these scenarios using a combination of text descriptions, activity diagrams (similar to flow charts), and sequence diagrams. When complete, the scenarios were fed back to the stakeholder (generally, to the marketing group) to confirm the requirements.

By undertaking this new workflow, the firmware team ensured that the application would meet all of the product requirements. Furthermore, the firmware team's understanding of the requirements was exactly the same as the marketing and science team's intentions. A benefit from this process was that they avoided rework due to missing, misunderstood, and misinterpreted requirements.

Architecture
As the use cases began to gel, the team began the architectural design. MDD benefited the team in two ways during the development phase. First, MDD improved communications markedly. Engineers are typically visual people and benefit from seeing the design rather than reading about it.

Software programming languages, unfortunately, are text based. Even in the days before UML, most developers used pictures to explain what the firmware was supposed to do. UML, while not a programming language like C or C++, does standardize the way engineers communicate about software/firmware. Employing an MDD process is the best way to see the software and firmware developed using UML.

Communicating graphically helped this team more than most because the sensor development teams work in different time zones and speak different languages. The corporation is based in Houston, Texas, thus most of team members speak English as their first language. But half of the development takes place in Europe by people for whom English is a second or third language.

In the past, subtleties of language and culture caused misunderstandings that resulted in significant rework. Describing behavior with activity diagrams and sequence diagrams removed the ambiguities about firmware design that exists when interpreting text, greatly benefiting the architecture workflow.

As the teams became more comfortable with UML-based designs, they found that their peer reviews actually worked. Since they did not need to read lots of text or code team members reviewed the technical content. Graphical representations led to technical discussions about the best way to implement requirements. Improved communications reduced rework, saving time and ultimately costs for the company.

Using MDD enabled firmware teams assigned to different sensor applications to work in parallel. The principal architects modeled the interfaces to common functions (e.g., data logging, I/O, communications) first. This model included stubs to the operations that the other applications would call.

While one firmware team implemented the common functions, the sensor teams used this infrastructure model as the basis for their applications' models. Developers designed, implemented, and unit tested their own application before the infrastructure was complete.

Not only were applications insulated from the infrastructure, they were also insulated from hardware platform changes. The downhole environment is extremely demanding. Temperatures exceed 302o F (150o C) with pressures up to 30 kpsi (2070 bar). The project tried to settle on a chipset before beginning coding, but no set met the operational environment requirements. Early on, program management and the firmware leads recognized that they could not wait for electrical engineering to choose a chipset before they began building the applications.

MDD allowed the teams to continue working without choosing a hardware platform or even an operating system (OS). The models abstract OS-dependent functions (e.g., semaphore, mutex, threading) from the application. Similarly, models abstract hardware-dependent functions (e.g., reading and writing I/O, setting timers). The application does not call any OS-dependent or hardware dependent functions. Rather, it calls the abstract functions. Changing the operating system and/or hardware requires modifying only a thin abstraction layer, not changing the entire application or test suite.

Graphical programming allowed the team to communicate, even across distributed teams that spoke more than one native language. Peer reviews were easier and quicker, since the UML models offered a clear picture of what the designers were working on. Multiple teams could work on the larger overall system concurrently, improving productivity. MDD allowed the team to abstract the application from the OS, so they could work on the applications with determining what hardware on the OS they wanted to use. Generating the Code
One of the key aspects of MDD states that the model, not the generated code, defines the system. The working configuration management archive stores the model, not code, because the model produces the code as an output. This organization, like many, feared model generated code would be unsafe or inefficient.

When they realized that the generated code was predictable, readable and efficient, the organization embraced code generation because they were able to produce better, more maintainable code in less time. As one of the team leads put it, their original fear of model-generated code was similar to the early 1980s fear that compilers would produce unsafe or inefficient code and therefore developers should write only machine or assembly code.

Another advantage to generating code directly from the model is the documentation is always up-to-date. This practice allows even safety-critical products to follow Agile development practices. In Agile development, teams iteratively add functionality to the product by focusing on working, executable code rather than documentation. In safety critical, government, and aerospace and defense projects, however, the documentation is a deliverable.

An MDD approach that uses model-generated code results in documentation that is always up-to-date. The developers concentrate on designs and tests. Developers can peer review the graphical model quickly, with confidence that the code will support the design because it comes directly from the design.

Model-generated code simplifies managing the development process as well. Since all developers see and understand all of the code, functionalities do not need to be owned by a single developer. The downside to not generating code from the model is that any model you develop is a static element. In the real world, code changes and having a model that is dynamically linked to the code is critical to keeping the model and the code in synch, making the model a truly living, up-to-date design element.

Unit Testing
Model based testing involves at least three levels: unit testing, integration testing, and acceptance testing. Unit testing confirms the operations perform as designed. MDD supports unit testing uniquely because the model contains both the tests and the subjects under test (the classes).

Typically, the developer builds tests at the same time he or she builds the functional classes. Using the OMG's UML testing profile, the developer automatically generates the subject under test (SUT) directly from the functional classes. The SUT is a small application with stubs that support all external interfaces called by the tested class(es).

Tests come from the designed activity diagrams, sequence diagrams, and state charts in the model. These tests may be coded using a testing framework like CppUnit or JUnit. Note that some modeling tools, like the ones chosen by this team, generate tests directly from the model artifacts.

Integration Testing
Once a developer confirms an individual block of code, he or she needs to confirm the work within the larger framework of the application — this is done via integration testing. Traditionally, the test team would try to force conditions that test the interfaces and the complex functionality. In an MDD environment, the team already came up with operational scenarios when they created use case for the newly added functionality.

The firmware team performs integration testing in several steps. The first step is for the developer who wrote the new code to compile his or her code with the existing application and run a limited number of regression tests. This step ensures that the new code builds and links with the existing design and it does not break any existing functionality. Performing this step protects the rest of the team from getting bogged down in compiler errors from new code.

Once the new code builds with the existing code base, the developer runs all new tests based on the newly implemented functionality's scenarios. These tests are similar to the unit tests, but now the new code interfaces are to the existing code, not stubs.

The developer fixes any integration problems and repeats this process. When the code passes all regression tests, the developer releases the code to the rest of the team.

At this point, the test team may access the existing code base too. They use the approved code base to confirm the test scripts. This practice shortens the overall development time because the development team and the test team work in parallel.

Integration testing was essential for this project because individual sensor applications depend on each other's system applications. The firmware team for each sensor must test changes within an integrated environment before assembling the entire application. Isolating newly generated code in its own "sandbox" ensured that changes to one sensor did not break the release code, avoiding delays during the testing phase.

Acceptance Testing
After completing integration testing, the sensor firmware teams passed the sensor applications to a formal test team that performed acceptance test. The formal test team's role is to make sure the application meets the requirements. Since the requirements were mapped directly to the use cases built in the MDD environment, the entire process went smoothly.

All the test team primarily had to do was run the use case scenarios developed during the requirements analysis phase. In these scenarios, the test team had the inputs and expected outputs, so testing was simplified.

Leveraging the DSP with MDD Gets Results
This project to build a new suite of downhole sensors was a success because the firmware team used an MDD approach when designing, implementing, and testing the applications. Though this approach is most often used in software applications, the team successfully used it to develop firmware applications targeted at DSPs.

The reasons why a DSP firmware developer would want to use MDD are clear — modeling the design solves nearly all of the firmware development challenges. MDD is the enabling technology that improves communication between developers because they create firmware designs in a standard graphical language. MDD helps developers derive and understand requirements. Mapping the requirements to named capabilities and to the application design ensures the application meets all of the requirements.

Modeling the design encourages developers to reuse common functions across products. Generating the code directly from the model guarantees that developers build the application to the designs. It also ensures that the model, code, and documentation are always synchronized.

MDD provides a clear and efficient path forward for developing DSP-based firmware successfully, as demonstrated in the case of this downhole sensor manufacturer; the process implemented not only provides a way for companies to remain competitive, but will also prove beneficial as a base for future projects.

About the authors
Martin Bakal is a Senior Application Engineer with Telelogic Modeling Division. He has a BS in Electrical Engineering from Tufts University, and he has also completed a Masters of Science in Engineering Management at Tufts University.

Jeffrey R. Cohen, P.E., is an Application Engineer with Telelogic Modeling Division. He has a BS in Mechanical Engineering from Carnegie Mellon University and a MS in Information Technology for Cappella University.