Challenges and lessons learned introducing Fuse, an evolving open source technology, into an established legacy Ada and C++ program
Background: When the FAA (Federal Aviation Administration) launched the System Wide Information Management (SWIM) initiative, the FAA had the goal of using the same portable, open infrastructure across all systems in the NAS (National Airspace System). In ~2008 the FAA chose Progress Software’s Free/Open Source Software (FOSS) based bundle known and supported under the Fuse brand. The licenses used by programs including EnRoute Automation Modernization (ERAM) were obtained by the FAA through Progress to use their Java framework. The name of the Computer Software Configuration Item (CSCI) for this SWIM client within ERAM is ERAM SWIM Application Service (ESAS).
Areas to be discussed:
- Development Challenges
- ERAM is an Ada/C++ near real-time system using a purpose built middleware with a DO278 Level C compliant process.
- Tactical Staffing can be a challenge when you have a large team using a common language and subset of the project using a different language it is harder to move folks back and forth.
- Best practice Coding Standards were already developed for the common project languages, adopting Java with the Fuse stack required augmenting the standards and toolsets.
- Formal Documentation on ERAM conformed to a DID (Decentralized Identifiers) compliant specification in the Statement of Work, adopting good Java practices with tool-generated design docs required working with the customer on process changes in addition to folding the tools into our toolbox.
- External Forces
- The Fuse product itself was undergoing a high degree of maturation change while development was proceeding.
- The rate of Fuse change contributed to reduction in future scope, had impacts when the system was updated to future Fuse versions.
- JBoss Fuse major versions can change which system is supported, e.g. spring->blueprint.
- Maintenance Challenges in a long-life National Airspace System (NAS) Critical System
- Since the original team was relatively small compared to the larger project staff, staff turnover of key positions had a greater impact on the remaining developers, and the use of common “popular industry tools” may have made it easier for some employees to find related work elsewhere.
- As the project usage and Fuse ownership evolved, we worked updates into the system to lower the total cost of ownership to the customer.
- Now that this area has been relatively stable for a long period and has had less “touch time” from developers, we are about to undergo a Tech Refresh and port platforms, and reconsider which (if any) of the system layers of the JBoss Fuse system will be utilized.
- Like the Java community at large, new JBoss Fuse versions bring in new features that impact CPU and memory, even if you do not intend to use the new features. But staying current with the product is often required for security patches.
- Test & Performance
- Java Virtual Machine as a runtime engine is very different from a C++ or Ada program. Ensuring the same level of NAS reliability required updating our Testing methodology.
- A Java Virtual Machine does garbage collection and Fuse adds a lot of extra processes to the runtime. Performance becomes harder to predict as Java Virtual Machine garbage collection is a “black box”.
Tuesday HILT zoom room – Tuesday HILT YouTube – HILT Clowdr Break Room