Trends in porting and abstracting applications in military systems
As today’s military electronics industry continues to evolve and increase in complexity, older technologies often become obsolete, creating a need for standardized development tools. These complex military applications can also present many challenges, including that of making OS-specific code run on a different OS. Thus, viable cost- and resource-efficient remedies to the problem include recycling and sharing software across multiple platforms via porting and abstraction.
The embedded industry continuously changes and evolves, oftentimes making older technologies obsolete and creating the need for more standardized development tools. Because military system applications are recurrently large and complex, adapting to the rapid rate of innovation can create overwhelming challenges. Accordingly, developers face obstacles in making OS-specific code run on a different OS and in designing with changing technologies in mind. Throughout the military and defense system industries, the idea of recycling and sharing software across multiple platforms is quickly becoming a popular way of thinking as it is decidedly cost and resource efficient.
Recycling applications on new OS platforms
Embedded software in military systems constantly evolves in order to keep up with the demands of changing market requirements, along with hardware and software platform technologies. These advancements often generate new system needs and may cause certain technologies to become obsolete, making necessary a platform upgrade or operating system change. Developers need to leverage their existing software and knowledge base rather than rewrite the software from scratch and throw away the investment made in the development.
As a result, the military industry has seen a growing interest in porting existing embedded software to an upgraded platform or new OS. This essentially allows developers to "recycle" their software, eliminating a costly rewrite and wasted investment.
However, making software written for one operating system run on another operating system is a daunting and time-consuming task with many error prone pitfalls as each OS is different in many ways. A quick example would be the levels of task priorities offered by each OS. Under standard Linux, for example, the priorities range from 0 to 99; for VxWorks, the range is 0 to 255; for LynxOS, the range is 0 to 512; for Solaris, the range is 0 to 169 priorities. Getting the software to run on a new OS platform with inconsistencies like these requires rewriting and reorganizing the software. To expedite such an involved task, developers need a tool that provides familiar APIs to eliminate the learning curve of a new OS and to reduce the projectís research and development time. This tool should handle problematic task priority variations, and other OS inconsistencies, to help legacy software easily adapt to a new OS platform (see Figure 1).
Sharing applications across OS platforms: Planning for the future
Military system applications are often large and complex and need to be able to communicate with each other and run across distributed computer systems with various operating systems. The Armyís Future Combat System (FCS), the largest DoD project to date, has been described by the Government Accountability Office (GAO) as "an unprecedented undertaking," one that "continues to grow as the demands of the FCS design become better understood."
For example, a recent article about FCS in The Washington Post notes that though the Army initially estimated 34 million lines of software, due to changes in the scope of the development, the new projection is 63.8 million.
Despite needed modifications to a design, it is not logical to reconfigure a system every time there is a change in an applicationís technical requirements or when new technology needs to be utilized.
In light of these issues, the industry as a whole is rapidly becoming aware of the need to plan for the future. Developers are looking to utilize OS abstraction tools to write highly portable software that allows for communication among multiple applications across various systems and that negates the need for future rewrites and expensive maintenance. However, designing an in-house OS abstraction is a complicated task, akin to designing a brand new OS that will need to fit the applications now and in the future. This takes a lot of development effort and maintenance, which takes focus away from a developerís core project.
It is difficult to design an OS abstraction with every feature and function that will satisfy all of the applicationís needs, so that it does not rely on the underlying OS for any features (for example: printf()). It also requires much effort to design an abstraction that allows for extending features in the future without losing the backward compatibility of existing application software. In addition, the design needs to account for the absence of some API features and functions that are only available on some operating systems, but not others.
A true OS abstraction should not only abstract the APIs, but the data types, header files, and symbolic defines as well. An OS abstraction needs to allow for adding new OS support quickly, without having to change the existing application software. However, this requires expensive testing by implementing the OS abstraction solution on multiple operating systems to ensure that it will allow the application to run on a different OS without software changes. When software changes are required to move the application to a new platform, it defeats the purpose of an OS abstraction design altogether. It is difficult to know every OS (or OS version) that the application will ever use, as that would require predicting the future in order to plan for all changes to the applicationís requirements. It is also difficult to correctly predict whether the operating systems planned for will always be available and current, as well as to plan for new operating systems not yet released.
To accommodate future needs and avoid such an intricate project, developers need a COTS OS abstraction to make developing portable software effortless. The abstraction needs to allow for design alterations without requiring a software rewrite, thus protecting the software investment. This abstraction tool should be engineered with safety-critical features vital to defense and mission systems, without sacrificing real-time performance (see Figure 2).
Protecting the OS investment
Military system developers need to leverage the existing knowledge base to eliminate a learning curve and protect software investment by developing portable applications. As an example, MapuSoft Technologiesí OS Changer and OS Abstractor give developers the ability to reuse software and adapt to future changes. These products are engineered to overcome OS inconsistencies and make developing portable code effortless, all while including advanced safety-critical and application performance features.
Marianne Crowe is director of marketing at MapuSoft, where she is responsible for all marketing activities from concept to execution. She also manages the international and domestic marketing teams and maintains partner relations. She can be reached at email@example.com.
Karin Barnard is a marketing intern at MapuSoft.MapuSoft Technologies, Inc.