September 26, 2000 -- DDC-I, a leading provider of real-time embedded system software development tools and services for safety-critical project developers since 1980, today announced the integration of the SCORECAST¹ automated test suite and support for the popular Windows NT development platform to the SCORE (Safety-Critical, Object-oriented, Real-time Embedded) suite of programming tools.

Already the first IDE (Integrated Development Environment) to offer multi-language, multi-target and multi-host capabilities based on non-proprietary open system standards, the SCORE IDE addresses the increasing need among project developers to combine reusable software components, often written in different languages, targeting different microprocessors, and created on different development platforms.

"SCORE’s primary purpose is to provide an easy-to-use environment that guarantees maximum software portability and code reusability to safety-critical embedded systems developers. The addition of Windows NT support is in direct response to the needs of our customers, like Boeing, Lockheed, and Rockwell, who are migrating their safety-critical software development for large projects like the Comanche helicopter to the popular NT platform," explains DDC-I Engineering Manager David Mosley.

According to Mosley, the four primary benefits of SCORE are: reduction of development costs via shorter design cycles; faster time-to-market for new and redesigned products; less total programmer hours invested per project; and overall risk reduction through code reuse and upgradeability.

Shorter time-to-market for new applications becomes possible by spreading software development across previously segregated programming groups. Excellent risk reduction can be achieved through increased component reuse and simplified target upgradeability. Because SCORE allows programmers to build using open standards -- Ada, C, ANDF, ASIS, POSIX, ELF/DWARF -- major application rewrites can be wholly avoided and dramatic reductions in overall project development costs are attainable.

"SCORE is also designed with features that facilitate large project management, debugging that doesn’t affect the performance of embedded code, and an efficient and certifiable Run-Time Operating System. Its strength is rooted in its ability to generate coherent, modular, and reusable software components, detect errors in the early stages of development, and quickly and efficiently retarget existing code," he adds.

The key components in SCORE are the next generation of DDC-I compilers. Based on ANDF (Architecture Neutral Distribution Format) technology, compilers for each language generate a common intermediate representation that is converted to the final object code during a later language-independent phase. Because ANDF is an XOpen standard, the SCORE system possesses a truly open architecture.

Using a GUI based on Win32 and OSF/Motif, while retaining a command-line interface option, the SCORE front-end incorporates project management tools, online help functions, tool activation, and a number of other efficient features. The GUI also offers a single universal interface for all compilers and tools, and the use of open standards means third-party products are easily integrated.

In addition, DDC-I has also added best-in-class automated module testing to SCORE’s list of features, in the form of the fully integrated SCORECAST test suite.

"The integration of SCORECAST into the SCORE IDE addresses the larger need to automate time-consuming manual testing and reporting of individual code modules, which is historically a time-consuming and tedious process, largely because so much has always been done manually," says Mosley.

The test automation offered by SCORECAST reduces the tedium and time-related expense of module testing via consistent and repeatable processes. Offering test methodologies and automated execution for each part of the module testing process, SCORECAST also generates comprehensive test reports that facilitate improved project management and earlier defect detection.

"Cost reduction is the driving force in embedded systems, and it’s very important to note that the financial benefits of SCORE don’t just apply to safety-critical applications, but to all real-time embedded system software development. DDC-I has added support for Windows NT and the SCORECAST automated test suite to the SCORE IDE to make the process of developing embedded systems applications as efficient and inexpensive as possible," Mosley concludes.

Riding Thalys, the stylish red flagship of the French TGV high-speed rail system, is a heady experience the first time you taste its extremely smooth version of ultra high velocity. Reclining comfortably as the Gallic countryside streaks past -- with nary a ripple in your glass of Bordeaux -- thousands of tons of metal and microchips hurtle you toward Paris at speeds up to 320 kilometers per hour. Few passengers, however, ever consider the importance of the embedded software keeping the train on track.

While the software behind Thalys’ neck-snapping speed and sterling safety record is transparent to most, to the engineers designing its successor, the ability to create dependable, failsafe systems on time and within budget is paramount. Fortunately, one phase of the European Community’s OMI (Open Microprocessor Initiative) Program, OMI/SAFE (Safe Ada For Embedded systems), provides a clear path to more flexible, less expensive software development for safety-critical real-time systems like those aboard Thalys.

Initiated in 1997, OMI/SAFE is the third piece of the $1 billion (US) ESPRIT OMI strategic development program. One of the primary goals of the overall program is to eliminate limitations confronting real-time embedded systems developers as they migrate software to different microprocessors or microcontrollers.

Successfully completed on September 30, 1999, the OMI/SAFE project was managed by Poul Munch of Lyngby, Denmark-based software development tools provider DDC-I. Other participants included Thomson Services Industrie and Crouzet Automatismes of France, automation solutions providers for the French TGV trains, and Germany’s iXpoint and University of Karlsruhe, providing software development expertise. Advanced Informatics of Greece and University of Karlsruhe subcontractor Advanced Bytes & Rights of Britain rounded out the project group.

"The OMI/SAFE program was really about giving developers more flexibility and mobility when they design systems, leaving them free to move between or even mix programming languages, and making it less expensive to migrate software to different processors," says Munch.

He explains that the OMI/SAFE project in particular was focused on proving the reliability and usefulness of existing ANDF (Architectural Neutral Distribution Format) technology, as ANDF is considered a pillar of the larger OMI strategy and the key to genuine software portability. In short, ANDF is the common, architecturally neutral representation of programs that have been coded in C, C++, Ada, Fortran, or Dylan.

The ANDF technology was DDC-I’s SCORE (Safety Critical, Object-oriented, Real-time Embedded), an integrated software development environment designed to address the need for combining reusable software components, written in different languages, targeting different microprocessors and developed on different development platforms.

According to Munch, the scientific objective of the OMI/SAFE project was to contribute to the definition and implementation of a complete development process for safety-critical software -- for real-time embedded systems -- that assured safety while still guaranteeing maximum software portability and reusability.

For OMI/SAFE, the project group synthesized three areas of technology and methodology:

1) Ada/ANDF technology capable of; supporting coherent, modular, and reusable implementation, detection of errors at early stages of development, and quick retargeting to other processors.

2) Formal methods and techniques for the verification of correctness and safety-assurance of system specifications and design.

3) Integrated safety and schedulability analysis methods

An experienced developer of embedded systems for the rail industry, Crouzet Automatismes contributed the design focus of the project: improving the performance of the pantograph, a parallelogram-shaped mechanism riding atop the train that makes contact with the overhead cables that provide operating power.

"Within the stringent TGV manufacturing rules, Crouzet Automatismes also planned to move their software development from C to Ada 95 using ANDF," Munch says.

Offering more detail about the application, Jean-Jacques Bardyn of Crouzet Automatismes explains that the new automated active damping mechanism developed during OMI/SAFE will provide more stable contact with overhead cables for the current generation of TGV trains. Improved pantograph performance is also crucial for the next wave of TGV trains, with a top speed projected at 350 kilometers per hour.

Bardyn adds that the project has been successful in transferring software originally coded in C to Ada 95 using SCORE technology. He also expresses satisfaction that the compilers proved so efficient that they were able to pack the resulting code onto an 8K EPROM, and operate the retargeted software using just 256 bytes of ROM.

"When we applied the project results to the application prototype everything worked perfectly. All that remains now is to build a full-scale prototype for field testing on an actual TGV train," Bardyn says.

Crouzet Automatismes’ counterpart on the software development side of the group was the University of Karlsruhe’s Dr. Gunter Schumacher, who also represented British subcontractor Advanced Bytes & Rights.

The basic drive of OMI/SAFE from his perspective was to conclusively show that new development tools and compiler technology capable of generating "industrial quality" software could be generated in a short period of time. He explains that the project remained true to the larger OMI goal of software mobility, and that improvements in development methodology offer the potential for significant cost savings.

For example, creating new tools and compilers to migrate C code to Ada 95 happened very rapidly, compared to what would normally be expected when retargeting software to a new processor. In his estimation, when the evaluation delays that a project like OMI/SAFE adds are removed, it took the equivalent of six months of steady work by just one programmer to generate the new products.

"OMI/SAFE has proven that Ada/ANDF compiler generating technology is mature," says Dr. Schumacher.

He also believes that the concept of software mobility underlying the larger OMI initiative in Europe is sound, and that industrial developers in the United States -- that have so far shown a lack of interest in ANDF -- would be well served to follow the European lead.

"It’s very important to note that the financial benefits of what we’ve proven don’t just apply to safety-critical applications like Thalys, but to all real-time embedded system software development. I think that once we have just one or two more successful demonstrations the rest of the world will take notice," he says.

With two new ANDF retargeting projects similar to the OMI/SAFE pantograph software development already proposed, it’s likely just a matter of time before Dr. Schumacher’s prediction is fulfilled.

"The OMI/SAFE project has proven conclusively that current Ada/ANDF technology is reliable and useful and that retargeting is no longer a problem," says DDC-I’s Munch. "Timing and fault analysis are now an integrated part of design and test. As a matter of fact, the testing tools provided actually satisfy one of the strictest testing guidelines for real-time safety-critical systems, the FAA RTCA/DO-178B Level A, which is required for all airborne electronic equipment."

Sometimes when debugging an executable and attempting to set a breakpoint or tracepoint at a source code position, the message that the code is optimized away is displayed. In some cases, this seems impossible because you know that code is executed when your program is run. How can this happen?

The debugger makes use of tables in the Ada program library to relate source code positions to addresses in the executable. If the address for a source code position as described in the Ada program library does not appear to be present in the executable, the message that the code is optimized away is displayed. One way that this can happen for code that has not really been optimized away is to debug an executable that was linked from one Ada library, but using a different Ada library. The debugger can not tell that the executable was linked from a different library, but can detect that the address the library says belongs to a source code position is not present in the executable, thus the messge that the code is optimized away is output.

If you see a message that code is optimized away, but you are sure that it must actually be included in your application, check carefully to be sure that the executable came from the library specified in the debugger invocation. When in doubt, relink the application from the library to be used for debugging.

Note: When selective linking is enabled, the only Ada routines linked in are those that are actually referenced in the program, so trying to set a break at a source position that is impossible to reach because it is never referenced may result in the "optimized away" message. Dead code may also be eliminated resulting in this message. Thus, the "optimized away" message does not usually indicate that your library and executable do not agree. But when you are sure that the code is not dead and is referenced, then there is a good chance that the executable and library do not agree.

If the message that the code is optimized away is displayed when trying to set a source code breakpoint or tracepoint and you are sure that that code is not dead and is referenced, then it may be that your executable was linked from an Ada library different from that specified in the debugger invocation.