Trends in porting and abstracting applications in military systems
StoryApril 02, 2008
Marianne Crowe
MapuSoft Technologies
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.
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).
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."[1]
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.[2]
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).
Figure 2
(Click graphic to zoom by 1.7x)
|
|
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
marianne@mapusoft.com.
Karin Barnard is a
marketing intern at MapuSoft.
MapuSoft Technologies, Inc.
251-665-0280
www.mapusoft.com
References:
- www.gao.gov/new.items/d07672t.pdf
- www.washingtonpost.com/wp-dyn/content/article/2007/12/06/AR2007120602836.html
