Vol.1 Num.1, August 2000
New Flexible Embedded Software Helps Developers Keep Pace with Advancing Processor Technology Validated by the European Union's OMI project, mature ANDF technology enables legitimate open system software development for real-time safety-critical embedded systems Constant advances in silicon architecture are making life difficult for developers in the safety-critical embedded systems arena. By the time many large projects are completed, increasingly in multiple languages, the original state-of-the-art target processor is nearly obsolete. In response, a new level of flexibility is emerging in the latest design tools, as evidenced by the recent release of DDC-I's SCORE (Safety Critical, Object-oriented, Real-time Embedded) integrated development environment (IDE). “Developers should be able to efficiently and effectively migrate their software to the latest targets in a timely manner. SCORE was designed specifically to address the growing need to combine reusable software components, written in different languages, targeting different processors and developed on different development platforms,” says Joyce Tokar, Ph. D., Vice President of Technology for DDC-I. The first multi-language, multi-target, multi-host IDE for real-time safety-critical embedded system developers based on non-proprietary open system standards, SCORE is a prime example of the improving flexibility of software design tools. Tokar explains that flexibility is paramount to reducing development costs via shorter design cycles, resulting in improved time to market for new and redesigned products. Fiscal benefits like fewer programmer hours invested per project and risk reduction through code reuse and upgradeability are made possible by the ANDF (Architecture Neutral Distribution Format) technology at the heart of the SCORE IDE. Serving as a programming lingua franca, compilers using ANDF first compile the source code — from C or Ada for example — into ANDF, and then from ANDF into machine code for the desired target. The first part of the compiler is called the “producer,” the second part the “installer,” with ANDF as the intermediate form no matter what language is compiled or which processor the code is generated for. When a new processor is designed, an installer and specific parts of a run-time system will be developed for the target. Once the installer is generated, compilers instantly exist for all programming languages that have a producer in place. Any existing applications in those languages can then be ported to the new chip. Achieving this level of code portability and reuse was a key reason for the original development of ANDF. “DDC-I has broad experience with the `bare-metal boys' in the safety-critical embedded systems field, and our focus remains on getting the best possible application performance out of each processor,” Tokar says. The foundations of the ANDF technology behind SCORE were originally built for use with C by the Defense Evaluation & Research Agency in the UK. DDC-I has subsequently been involved in developing extensions to ANDF that make it suitable for use with multiple high-order languages. “ANDF together with ELF/DWARF, POSIX, and ASIS is they key to developing open compiler systems capable of eliminating the barriers to multi-language development, and DDC-I is open to working closely with other compiler vendors to create an open tool set based on these emerging standards,” says Tokar. A glance across the Atlantic reveals ANDF playing a key role in the long-range strategy of European embedded system developers. Their open systems approach is a direct result of the European Union's ESPRIT OMI (Open Microprocessor Initiative) program, a large-scale research & development thrust initiated in 1989 to resuscitate a flagging European embedded systems industry. Nearly a decade later OMI was generating results. In 1997, sales by microelectronics suppliers as a direct result of R&D performed via OMI were estimated above 500 million Euro. Projections for 2000 top 2 billion. “Since cost reduction is the driving force in embedded systems, a vital part of the OMI mission has been to create tools to reduce the design cycle, improve time to market, and facilitate code reuse,” Tokar says. According to Tokar, DDC-I has been instrumental in advancing ANDF standards during three successive OMI programs. OMI/GLUE (Global Language support and Uniform Environment) consolidated ANDF development within the larger OMI program, extending ANDF to handle Ada and C++. OMI/CORE (COmpilers for Real-Time Embedded) focused on developing ANDF for real-time embedded applications. Successfully completed in October 1999, OMI/SAFE (Safe Ada For Embedded systems) enhanced and validated ANDF as a development tool for a safety-critical application to improve the high-speed performance of the next generation of French TGV trains. While ANDF installers now exist for many high-end processors, the crux of the OMI/SAFE project was the rapid development of an installer for the ST9 microcontroller. The project was successful in transferring software originally coded in C to Ada using SCORE, and the compilers proved so efficient that the resulting code fit onto an 8K EPROM, while the retargeted software operated using just 256 bytes of ROM. “Since space is still limited in the embedded world, efficiency was a major concern as we developed the SCORE compilers. The results from OMI/SAFE validated our approach and our philosophy that nothing extra should reside on the chip, only what the developers ask for,” says Tokar. Managed by Poul Munch of DDC-I, other participants included TGV contractors Thomson Services Industrie and Crouzet Automatismes of France, Germany's IXpoint and University of Karlsruhe, Advanced Informatics of Greece and subcontractor Advanced Bytes & Rights of Britain. “OMI/SAFE has proven that ANDF compiler technology is mature,” says Dr. Gunter Schumacher, a software development expert from the University of Karlsruhe participating on the project. In his estimation, it took the equivalent of just six months work by a single programmer to generate the finished product. He also believes that the concept of software mobility underlying the OMI initiative is sound. “It's very important to note that the financial benefits of what we've proven don't just apply to safety-critical applications, but to all real-time embedded system software development,” he says. Schumacher's assertions about the cost-effectiveness of ANDF technology come at an opportune time for the entire industry, as the per chip cost of embedded software continues to trend upward. This is a major concern, especially in volume markets, where in some cases it exceeds the actual cost of the silicon. “OMI/SAFE was about giving developers more flexibility and mobility when they design systems. Our goal was not to get in their way, leaving them free to move between or even mix programming languages, and making the process of migrating software to new processors as inexpensive as possible,” says Tokar. According to Tokar, another emerging trend is the tendency of newer engineers to prefer using tools that resemble the Windows systems they often grew up with. With this in mind SCORE uses a GUI based on Win32 and OSF/motif, while retaining a command line interface option. 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 into the environment. Project management features simplify the coordination of complex development programs, and an enhanced library management system keeps the team together on exceptionally large projects. Considerable time can also saved by taking advantage of the system's parallel compilation abilities. SCORE's robust tasking and non-tasking RTOS lack the overhead and subsequent lower speeds of off-the-shelf products. The multi-language debugger handles the debug information such that no additional target memory is required for debugging, and the lack of code insertions allows for easier certification. By enabling the compilation of programs created by multiple developers, using tried and true modular components from an already certified library, costly re-certification can also be minimized. SCORE currently supports coexistent development in Ada and C, with C++ support forthcoming. The target microprocessors initially supported are the Intel 80x86, Pentium, and PowerPC. Additional targets, as well as support for other languages like JAVA, will be included as requested by developers. By design, the nature of SCORE's architecture offers the ability to more affordably move applications to another target, and fast — or secret — retargeting to target architectures of the future. “OMI/SAFE proved conclusively that ANDF technology is reliable and useful and that retargeting is not a problem. Timing and fault analysis are now an integrated part of design and test, and the testing tools provided with SCORE 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,” says Tokar. Ada Helps Boeing Cut Costs on Comanche Boeing pushes the envelope of team-oriented embedded software development, using Ada’s advantages to drive down system design costs on the Comanche helicopter Safety-critical embedded systems — where system failure is measured in human lives as well as dollars — originated in the defense industry, and nowhere do they remain more important than on the modern electronic battlefield. The RAH-66 Comanche helicopter, currently in Phase III development with The Boeing Company and Sikorsky Aircraft Corporation, offers irrefutable proof. A massive leap forward in helicopter design, the Comanche is America’s attack helicopter for the 21st Century. Created to serve a dual role as both a pinpoint accurate close air support tool and sophisticated mobile reconnaissance platform, it depends heavily on safety-critical systems to control the crucial tactical assessment, fire control, and pilotage systems that comprise its Mission Equipment Package (MEP). The tactical "mind" of the Comanche, the MEP is capable of providing accurate real-time pictures of front line action to the entire military command and control team. Merging supercomputer intelligence with next generation battlefield sensors using digital interconnectivity, the MEP provides the Comanche with a level of low-altitude field reconnaissance capability that dramatically exceeds any previous military attack aircraft. The MEP was originally created when the Ada software programming language was mandated for military projects by the Department of Defense (DoD), but Boeing’s Phase III work is no longer covered by the order, which was lifted in 1997. However, as Boeing began Phase III, they were also implementing a new company-wide "synergy" policy. The result has been the creation of a more cost-effective, team-oriented approach to hardware and software development as they design the MEP systems used on the Comanche. Boeing Senior Staff Engineer Gerry Furniss, the Integrated Product Team Lead responsible for both the target acquisition and pilotage systems on the helicopter, explains that Boeing’s choice to stick with Ada in Phase III was motivated largely by the fact that it would facilitate the new cost reduction strategies. "We were making significant changes in our overall development model and looking for less expensive ways to handle software development," he explains. "As it turns out, Ada’s package specs lend themselves very nicely to how we decided to divide up the old design and review processes." Ada’s clear advantages over other programming languages in multi-programming applications are helping Furniss and the Boeing Comanche team realize significant changes in how they manage multi-project software development. For the first time, instead of each individual MEP system representing a single project, Boeing is pioneering a "round table" approach. With a directive from upper management to reduce costs and improve software development processes, they began to move away from the traditional Preliminary and Critical Design Review (PDR/CDR) model. According to Furniss, the new "In-Process Review" (IPR) cycle that gathers the vendors, Boeing teams, and the provider of the Ada software development platform, Phoenix, Arizona-based DDC-I, is achieving the desired results. "Using IPR’s, as opposed to traditional software development methodologies, is proving very fruitful, especially in the area of communication. By getting the teams together up front and keeping everyone talking, we’ve really been able to enhance our team-oriented approach," he states. By gathering all the vendors on a uniform development platform, the individual teams learn collectively, dramatically reducing inevitable redundancies between the project teams. The uniform development platform being used is the DDC-I Comanche Ada Compiler System (ACS), proposed by DDC-I when Boeing updated the processors in the MEP from the older Intel 960 to the newer Pentium. The Comanche ACS being developed for Boeing by DDC-I is based on the proven DDC-I Ada Compiler System (DACS). Serving as the central hub around which the entire Comanche MEP software development team designs their individual systems, it contains a number of proprietary modifications designed specifically for Boeing. Alongside their already unique debugger technology, DDC-I also created a custom version of their leading run-time system which addresses specific Comanche requirements. "Boeing’s choice to remain with Ada on the Comanche sends a clear signal that Ada is still the language of choice for large-scale, safety-critical embedded system development," explains Joyce Tokar, Ph.D, Vice President of Technology at DDC-I. Beyond her role as DDC-I’s chief technologist and visionary, Tokar is also an executive member of the Ada Resource Association board, an industry panel guiding future development of the Ada language. "Despite predictions of its demise after the DoD lifted the Ada mandate for defense contracts in 1997, Ada usage is actually increasing and industry recognition of Ada’s advantages in code reliability, reusability, readability, and portability is on the rise," she adds. The hard numbers back Tokar’s assertions about Ada. In studies conducted during the eighties Ada consistently outperformed established programming languages like Pascal, Fortran, and C. In the nineties, Ada continues to surpass C++ in performance evaluations measuring capability, efficiency, maintenance, risk, and lifecycle cost. The current trend at Boeing also bolsters Tokar’s assessment. When the management directive that motivated Furniss and his team to establish the new IPR process also encouraged standardizing software development to a single commercial language like C++, there was a great deal of concern among the team members about moving away from Ada. "There is a huge reluctance to move to C++ and it’s not because of the language, it’s because of the structure around the language," he details. "There are so many variants of C and C++, and they’re not as well structured as Ada, so even though you may settle on the same C++ language the coding standards that go with it are always different. You’ve got to put a shell around it, where Ada already has one." Ada was originally created in the late seventies, as a logical alternative to the proliferation of software languages being used by defense contractors. Successfully completing its early mission, Ada reduced the total number of high-order programming languages in use from over 450 when it was released in 1983 to just 37 by 1996. This success was based on the principles guiding its creation, which stated that the language must be developed with sound software engineering principles in mind and capable of handling large, complex projects. It also had to be standardized, validated, reliable, and maintainable. Ada use continues to rise — despite the lifting of the DoD mandate — because it still supports these primary goals for major projects like Comanche. A crucial Ada strength is the early identification of programming errors typically detected much later with other languages. Since Ada catches the majority of coding glitches at compile-time, before run-time or system integration and deployment, programming errors are less damaging to project schedules and less expensive to repair. Viewed from purely business perspective, Ada’s primary advantage is in its support for open systems and interoperability. However, a list of other "ilities" also contributed to the higher programmer productivity and lower lifecycle cost that were part of Boeing’s decision to choose DDC-I’s Comanche ACS:
"The truth is that Ada will not go away in the foreseeable future," DDC-I’s Tokar emphasizes. "The DoD has an enormous investment in Ada, and major embedded systems written in Ada like those in the Comanche will be in service well into the next century." Acting as a central "hub," the Comanche ACS — in this case the debugger and run-time system — is integrated into the MEP operating system (OS) by the Comanche OS team in Wichita, Kansas. Once integrated, each OS release is sent out to the suppliers, where it is used to generate the firmware and software for their applications. "This approach is proving cost-effective because we’re all using the same tool at the integration point," Furniss affirms. "We all come up with the same concerns, but nobody has to reinvent the solution. We’re able to cross-pollinate in terms of answering questions and solving problems, and DDC-I is also part of the working group that includes the suppliers to help deal with any issues that arise." DDC-I’s Tokar stresses that the most significant benefit Ada offers often isn’t even considered when the choice between development languages is made. "When you look at computer systems from the total lifecycle perspective, research has determined that between sixty and eighty percent of costs occur after development and implementation. In other words, the maintenance phase accounts for the lion’s share of the costs in traditional projects." Since procurement decisions are typically driven by development costs and maintenance is typically handled as a separate contract on most projects, this creates an artificial division in the lifecycle that makes it far too easy to overlook maintenance. Basically, a decision based exclusively on the first phase costs is only considering twenty to forty percent of the total possible project expenses. "Ada was developed with good software engineering practices as a founding principle and remains the only internationally standardized programming language specifically designed to address large, complex applications like the Comanche MEP," states Tokar. "For real-time, safety-critical embedded systems applications Ada is still the leader." Though as a Boeing employee and DoD contractor Furniss has to stop short of personally endorsing the Comanche ACS, he agrees wholeheartedly with Tokar’s views on the benefits of Ada for software development on safety-critical systems. "Ada is a language designed to be used in a team environment, and our team approach is a nice way to do business. It creates a very positive, collaborative environment with the vendors," he concludes. "I think the movement at Boeing is a smart one, and it will become even more obvious because we did save money." Real-time Sampling of Critical Sections It is often necessary to demonstrate timing requirements within a critical section of a program. The Tartan tool, AdaTrak, provides the necessary tools for providing real-time sampling of critical sections of code and profiling data which allows a developer to optimize the critical timing areas within a program. AdaTrak receives its data from the TADS Ada Runtime System and from AdaScope, the TADS source-level debugger. Data from a single run of an application program can be analyzed, or several iterations can be combined to generate a picture of average execution over a wider range of input. You may choose to perform profile analysis on the entire application program, or to profile only the subprograms in a subset of the compilation units. Profiled and non-profiled units may be mixed freely, and profiling can be disabled when the program is linked. AdaTrak produces three kinds of analysis of the target program:
AdaTrak is designed to be effective in analyzing programs running on embedded systems. It requires no additional hardware support because it uses the timing facilities native to the target processor. If a more accurate clock is available on custom hardware, AdaTrak can be configured to use it for timing analysis. AdaTrak can also be configured to minimize utilization of processor memory or communications overhead depending on the program's resource requirements. Finally, even though AdaTrak works in software, it imposes minimal execution time overhead, and eliminates most of the execution time overhead from its own analyses. |