COTS software challenges in the military electronics market
StoryApril 09, 2015
COTS CONFIDENTIAL. Every month the McHale Report will host an online roundtable with experts from the defense electronics industry – from major prime contractors to defense-component suppliers. Each roundtable will explore topics important to the military embedded electronics market. This month we discuss the outlook for embedded COTS software in the defense electronics market.
This month’s panelists are David Egts, Chief Technologist, U.S. Public Sector at RedHat; Robert Dewar, Cofounder and president of AdaCore; David Barnett, Vice President of Products & Markets at RTI; Greg Rose, Vice President of Marketing and Product Management at DDC-I; and Chip Downing, Senior Director, Business Development, Aerospace and Defense at Wind River Systems.
MCHALE REPORT: Not withstanding the increase in the FY 2016 budget request, sequestration and cutbacks in the Department of Defense (DoD) budget in recent years has created a push toward more commonality. How does this trend affect the demand for COTS software?
EGTS: Reduced funding forces a focus on the mission and optimization everywhere else. Over time, this optimization resulted in the transition away from a myriad of expensive Unix variants to Linux, but still the number of Linux variants proliferated. With further cutbacks, programs have often focused on standardizing on one Linux variant that’s commercially supported. Not only does this free the program to focus on the mission and let a COTS vendor do the support, the program has a larger talent pool of COTS-certified employment candidates to draw from. Further, certification and accreditation (C&A) is a lot easier with a standardized operating environment.
DEWAR: The push for more commonality is indeed related to the demand for COTS software; the answer is, however, not simple. On the one hand, developing highly specialized non-COTS software leads away from commonality. On the other hand, COTS software tends to move rapidly and be oriented to the latest version with latest features, and not so much to the maintenance of old legacy versions. For long-lived DoD projects, this means that the mere fact that several projects nominally use the same COTS software may not mean that much if different projects use different versions with different patch levels, etc.
BARNETT: RTI’s software is primarily used to implement an open architecture. So most of the demand is driven by the push toward commonality – specifically, DoD’s goal to have open, modular systems with more reusable and interchangeable components.
ROSE: Interoperability and modularity are key to software commonality. In recent years, government and industry have come together to enhance interoperability and modulatory by fostering software standards such as ARINC 653 and FACE (Future Airborne Capabilities Environment), which embraces both ARINC 653 and POSIX. These two standards enhance software commonality by defining standardized interfaces and architectures that facilitate interoperability and reuse. Together, these standards provide a foundation for a COTS-software ecosystem that enhances profitability for suppliers while lowering cost, easing integration, and maximizing reuse for customers.
DOWNING: Any trend towards more commonality for widely used software will always increase the demand for COTS software. If there is industry/customer demand for a common interface or platform, this demand will drive more vendors to supply solutions for this platform, with differentiators that distinguish their software product from competitors. In a highly-connected and/or Internet-of-Things (IoT) environment, having common components and applications interfaces is a core requirement of a living IoT ecosystem, and these standards enable a wider range of solutions from a larger supplier base Standards like Future Airborne Capability Environment (FACE) drive the foundation of IoT systems.
MCHALE REPORT: Some in the DoD engineering community still get nervous when they hear the term “COTS software,” fearing it comes with the Windows “blue screen of death.” How does COTS software today combat those perceptions?
EGTS: The “blue screen of death” is often encountered when poorly tested third-party drivers are added to systems. If these drivers are for a product with a limited addressable market, the testing pool consists of the vendor and this small community of users. If the code is proprietary, only the vendor can view, develop, debug, and improve upon it. This is literally a recipe for disaster when lives are on the line.
Two things can be done to address these problems: First, the code should be open-sourced. This way, not only the vendor can view, develop, debug, and improve upon the code, but the DoD engineering community can help too, resulting in a better product. In the book “The Cathedral and the Bazaar,” this concept is defined as Linus’s Law, where “given enough eyeballs, all bugs are shallow.”
Second, the code should be generalized for mainstream use as much as possible. This would further increase the user base, which provides vendor feedback resulting in a better product and also creates an alternative revenue stream to increase the commercial viability of the COTS vendor. We’ve seen plenty of embedded companies come and go with niche products. One of the reasons why they’ve gone out of business is because they don’t have enough customers to sustain their business. By attracting a mainstream audience (think Maker movements with their Raspberry Pis and similar devices), they attract a new and broader customer base resulting in a better product, a more diversified product portfolio, and a more viable business model.
DEWAR: It’s reasonable to get nervous about unreliable software, and indeed a lot of generally available COTS software (for example, most versions of Java) come with a warning that use on critical projects is not advised. However in practice, the mere fact that software is COTS is a guarantee of neither reliability nor unreliability. There is terrible proprietary software around, and terrible specially developed software, and yes, terrible COTS software. But there are also excellent reliable products in all these categories. Any acquisition of software must be done in the context of serious evaluation of suitability. It would be as foolish to reject COTS software as inherently unreliable as it would be to assume that proprietary specialized software is necessarily reliable. Indeed, some of the biggest debacles in software have come from the failed attempt to generate specialized software for critical tasks.
BARNETT: DoD is not unlike any other market. There are innovators that will try unproven software because they see the long-term benefits. And there are pragmatists – generally with shorter-term deadlines – that will only adopt your software once it is proven. To win over the pragmatists, you have to prove your software with the innovators.
DoD has a standard means to measure the maturity of technology (including COTS software) in terms of its Technology Readiness Level (TRL). TRL 9 is the most mature, and requires that the technology be proven in a real system under real mission conditions. For most applications, we have not encountered concerns over the use of software proven in deployed systems.
ROSE: Verified correctness achieved through rigorous adherence to DO-178 guidance effectively puts these fears to rest. DO-178 has been used as the guidance for “proven correct” flight-critical software since the 1980s. Software that conforms to this guidance has been developed and verified to follow design assurance levels tied to system safety assessments and requirements and deliver safe operation. Software developed to this standard has logged millions of flight hours and currently manages all software aspects of flight around the world. This extensive history of unfettered operation has given software developed to DO-178 a reputation for the highest quality.
DOWNING: COTS military software suppliers have developed strong testing and integration processes to keep the level of quality at an appropriately high level. These COTS software products also may have complementary software certification artifacts that can be used at very high levels of safety and security, like RTCA DO-178C DAL A and Common Criteria, like Wind River’s COTS certification evidence for our products.
MCHALE REPORT: When Linux first came on the scene many thought it would not be a long-term military tool because – being open source – it was inherently insecure. Is that still the case? What inroads has open-source software made within military systems?
ROSE: Open-source platforms such as Linux are best suited for applications such as networking that have a Low Design Assurance Level. However, these applications can be incorporated into flight-critical systems by utilizing a certifiable time- and space-partitioned COTS operating system such as DDC-I’s Deos. In this scenario, the Low Design Assurance open-source Linux applications are run in a protected partition separate from High Design Assurance flight-critical applications. This partitioning allows the Linux applications to co-exist with the flight-critical software without compromising the overall safety of the system. We have seen increased usage of open source software in many military applications.
EGTS: Security is one of the strong points of Linux over other operating systems. Organizations like the National Security Agency (NSA), Red Hat, IBM, and others worked on Security Enhanced Linux, or SELinux, for well over a decade. Today, SELinux is enabled and enforcing in every copy of Red Hat Enterprise Linux shipped; SELinux enabled Red Hat Enterprise Linux to achieve the highest Common Criteria Certification possible for a general-purpose operating system (EAL 4+).
Commercial support also strengthens the security of Linux and funds a team of security engineers to not only do the certifications, but also to track and remediate vulnerabilities and proactively perform code analysis to prevent vulnerabilities from happening in the first place. Unlike proprietary vendors who can hide security flaws behind binaries, open-source vendors are incentivized to be vigilant when it comes to security as their code is available for all to see. Some vendors like Red Hat go even further by publishing risk reports stating how well they do in response to security vulnerabilities and publishing security measurement data in Open Vulnerability and Assessment Language (OVAL) format several times a day for end users to measure exposure themselves.
DEWAR: Many DoD systems are developed using COTS software (for example, GNU compiler software running on Linux), and an increasing number of critical systems are deployed on various versions of Linux. There is nothing inherently insecure about open-source software, and indeed you could repeat the answer to question number two, substituting “open source” for “COTS.” Recently we have seen speculation that future versions of Microsoft Windows may be open-sourced, but I don’t think that would or should mean that people would suddenly regard Windows as less secure.
There is an interesting debate on security. Does one achieve better security by keeping software secret and proprietary (makes it a bit more difficult to find security holes) or by making it open source (more eyes to spot possible problems)? There are energetic arguments on both sides, but not much data, and the best judgment is probably that it does not make a difference. There is highly insecure proprietary software around, and highly secure open-source software. Again, the burden is on any software acquisition to ensure suitability for use.
BARNETT: Opinions are still divided over the security (or insecurity) of Linux. In general, it seems well accepted. The exception is applications with safety or very stringent security requirements. In these cases, other operating systems with the necessary certifications are used, or hypervisors are used underneath Linux to provide the necessary isolation and separation.
From our vantage point, we haven’t seen other open-source software get the same level of traction as Linux. This could have as much to do with its maturity as with concerns about security. When it comes to safety standards like DO-178C, most open-source software can’t be certified because it wasn’t developed to the appropriate standards and following a rigorous quality process.
DOWNING: It is interesting to see the change that the entire community has experienced with open source – as stated, Linux started out as an insecure platform, but we have now seen that open source allows for many eyes to review and optimize code. This allows for high levels of trust and therefore extensive use within military systems. Products like Wind River Linux that come with full traceability to source code and a full build environment, not only have a strong commercial support model, but also allow for replacement of any code that one deems unacceptable from any perspective. In addition, any code base, including open source code, can be built to conform to a security standard, such as SELinux or a Common Criteria protection profile, which can greatly improve its security properties and its assurance. Robust, multi-OS hypervisors further enable an expanded use of Linux mixed with more critical code with tighter real-time response constraints. Furthermore, these advanced hypervisors allow the mix of more trusted code with less trusted code, so deployments of new capabilities can be accelerated into the field.
MCHALE REPORT: What are the biggest challenges for embedded COTS software suppliers in the defense market?
BARNETT: The biggest challenge is displacing the incumbent technology, typically a custom-developed solution. Even though there is a long-term savings from COTS, an upfront investment is often required to integrate it. This investment competes against other funding priorities.
ROSE: In some cases, the inertia of legacy software and systems drives the product or platform requirements. It is well accepted in the industry that portability and interoperability allows lower overall costs for system developers. However, in some cases, there is a strong desire to use components that may have been developed prior to the availability of standards. This is especially the case in applications where only minor modifications are needed. In these cases, the incumbent developers of the proprietary systems have a distinct advantage and a strong desire to retain the “vendor lock” to limit competition for enhancements and add-on features. This lock can only be broken when the customer makes the strategic decision to forgo the near-term cost savings of short-term fixes for the long-term cost advantage of migrating to modular, interoperable COTS software utilizing open-standard interfaces.
DOWNING: The biggest challenges for embedded COTS software suppliers are safety and security. When the industry standardized on a few popular single core computer systems it was easier to invest funds to create very powerful COTS safety and security evidence. Now that the industry is expanding into many different multi-core processors at a very rapid pace, both COTS software suppliers and our customers are challenged to create affordable, proven safety and security solutions.
EGTS: Managing technical debt. If COTS software suppliers develop proprietary code in-house, they need to shoulder the burden of 100 percent of the engineering, maintenance, and retrofitting of new features for the lifetime of the product. Over time, this maintenance cost becomes more and more expensive as the code gets cruftier, as people retire or move onto other jobs or roles, and as the hardware the code runs on is no longer available, thereby needing porting to new hardware platforms. Another problem with proprietary code is that it’s easy to fall into the trap of writing code poorly because only the vendor can see it.
By open-sourcing their code, they can share the innovation and maintenance costs with a community. They are also incentivized to write higher-quality code because it’s public for all to see, and better-written code encourages greater community collaboration, which helps lower engineering and support costs.
DEWAR: If I were to name the biggest challenge, I think it would be to properly understand the very long life cycle of many defense projects and properly accommodate these long-term requirements. In addition, it is important to understand that this is a market where reliability and security are more important than whiz-bang new features in frequent software upgrades.
MCHALE REPORT: What defense-market niches represent the best growth areas for COTS software providers? Avionics? Unmanned systems? Electronic warfare? Cyberdefense? Radar? Other?
DEWAR: All these areas are ones where absolute reliability is critical, and where safety- and security-critical concerns are paramount. Most COTS software is oriented to competing with rapid new deployment of new features, and very often we see that a lot of commonly used COTS software is very unreliable from a security point of view, and definitely not designed for safety-critical applications. The increased focus on certification and demonstrating safety and security properties means that this area can be addressed effectively by COTS software that understands the importance of these requirements.
BARNETT: In our case, in terms of growth, it is first, unmanned systems and avionics, which are increasingly coupled due to unmanned aircraft systems (UASs), and second, air and missile defense, which includes radars. Naval systems are also a large market for us but not growing as fast because our technology has already been adopted by the major programs.
ROSE: We expect the best growth area for our DO-178-certifiable software to be unmanned systems, though we expect to see continued modest growth across the avionics space in general. As more commercial uses of UASs are seen in the passenger-saturated commercial airspace, we expect to see a muddling of DoD UASs and the new commercial-focused systems as they are integrated into the commercial airspace. With this integration, the vehicles will most likely have to follow the same safety requirements that have been in place for air transport, business, and general aviation for commercial airspace for the past few decades. Both military and commercial applications will benefit from the software correctness that is delivered through the rigors of DO-178 guidance. For this market, we expect COTS-certifiable operating systems like Deos to deliver the lowest risk and fastest road to vehicle certification.
EGTS: Fueled by open-source software and hardware, the Internet of Things (IoT) movement has the potential to make a lot of the defense-market niches mainstream. It also has the potential to bring mainstream IoT ideas and products into defense-market niches, resulting in lower cost and higher quality products for the DoD. In the same way mass-produced Linux systems made overpriced Unix systems obsolete, mainstream and mass-produced IoT components have the potential to significantly disrupt expensive defense-market niche incumbents. This could be a financial blessing for incumbents who embrace IoT and a curse for those who don’t.
DOWNING: As our global militaries transition from electronic systems supporting kinetic warfare engagements to more non-kinetic -- intelligence, surveillance, reconnaissance, and targeting (ISR&T) and cyber operations -- all of these types of systems, including avionics, unmanned, electronic warfare, cyber defense, and radar will experience significant growth. Another area, autonomous sensing systems, will also see high growth to support the vast array of unmanned autonomous systems on the ground, sea, and air forward of our warfighters to provide real-time situational awareness into a combat cloud forward that enables faster decisions to be made in the battlefield. .
The most critical aspect of intelligence gathering is providing useful information to customers via data fusion and analysis. Improving the efficiency and cloud mobility of this tasking, collection, processing, exploitation, and dissemination (TCPED) of intelligence will provide the highest benefit to the intelligence community in the near future.
