Proprietary F-35 Software May Adopt Open Architecture For Fu

[bring_it_on]

Stovepiped, Proprietary F-35 Software May Adopt Open Architecture For Future Upgrades
Defense Daily | 07/21/2015 | Dan Parsons

BALTIMORE — The future airborne capability environment (FACE) consortium is working with the F-35 Lightning II program office in anticipation that future upgrades to the aircraft’s avionics software will be open to vendors other than Lockheed Martin [LMT]

Unfortunately this is all that is publicly available..I hope someone subscribes and can share more details. A twitter search on the author's profile gave us this..appears to be from a press conference or presentation FACE consortium held recently..

[smsgtmac]

Can't read the 'article' behind the paywall but it sounds like a bunch of public relations/sales hoo-haw.
First LM is part of the 'coalition'.
Second, the entire software architecture of the F-35 is designed to be modular and hardware independent. The most important aspect of the selected approach is how it allows the modularity to be done securely (MILS architecture). The F-35 approach is an evolved one based on lessons learned on the F-22 program (good PPT background here).

[Gums]

Salute!

Hey SgtMac!!! Remember Ada?

I watched system after system get waivers so the sftwe geeks could do fancy things with C+ and C++. About the only "standard" I saw enforced was MIL-STD 1760 and the data bus standards - NATO allies held out feet to the fire, and we were the only folks developing new, cosmic weapons for the most part.

As a diehard system engineer and strong believer in interoperability, it pained me to see the demise of Ada. There were no rewards for developing efficient compilers and likewise no rewards for older systems to join the movement. I had to work with every plane and some helos in the inventory, and about all the weapons from 1968 or so to 1996. Our company integrated all these things and tried to save taxpayer $$$ and still make our own $$$. So I had to figure out a kludge to use the Maverick interface to target and program the Harpoon, heh heh. My A-12 work went into the cloud when the program was cancelled.

"standards" are great, and only a few exceptions should be allowed if our various services and partners wish to have a formidable capability.

Gums sends...

[smsgtmac]

I sure do remember it. It was a great leap forward but basically got killed* by OOD and visual tools coming out of the same fuedal/tribal commercial sector that had up to that time caused the need for Ada in the first place.
Fast forward to 2002... I'm returning to system test in the labs from R&M Engineering and OR after a 7-year itch and it's 'UML this' 'UML that'. Can't afford to be out of date so I get LM to let me attend their JSF-specific 'UML' classes. I'm about 3 slides into the first handout reading ahead and realize pretty much all UML was is OOD tarted up after Booch and the other Amigos hashed out and settled their differences. The tools were 'new', but that's about it. Even then, UML tools were still so immature we were using one big player's product for 'requirements' and another big player's stuff for producing code. Continuity problem solved itself when one bought out the other. The REAL eye opener for me was seeing how immature all the new bus protocols (Fibrechannel and Firewire mostly) were compared to the granddaddy 1553/1760. Part of it was as if the steering groups had too many hands on the wheel, but the biggest part of it IMHO was there were legions of software engineers just dreaming up more stuff they could do with the bandwidth provided and every industry involved had a pet technique or twelve they wanted to bring. I have no idea how the last six years or so have played out in that arena, but it's comforting to know if I go back that I don't have to keep as current to to be able break code as I would have to be to write it - or rather 'drop stuff in swimlanes and hit compile' (I kid...some).
*Though Ada picked up some tricks from the victors.

[KamenRiderBlade]

I sure do remember it. It was a great leap forward but basically got killed* by OOD and visual tools coming out of the same fuedal/tribal commercial sector that had up to that time caused the need for Ada in the first place.
Fast forward to 2002... I'm returning to system test in the labs from R&M Engineering and OR after a 7-year itch and it's 'UML this' 'UML that'. Can't afford to be out of date so I get LM to let me attend their JSF-specific 'UML' classes. I'm about 3 slides into the first handout reading ahead and realize pretty much all UML was is OOD tarted up after Booch and the other Amigos hashed out and settled their differences. The tools were 'new', but that's about it. Even then, UML tools were still so immature we were using one big player's product for 'requirements' and another big player's stuff for producing code. Continuity problem solved itself when one bought out the other. The REAL eye opener for me was seeing how immature all the new bus protocols (Fibrechannel and Firewire mostly) were compared to the granddaddy 1553/1760. Part of it was as if the steering groups had too many hands on the wheel, but the biggest part of it IMHO was there were legions of software engineers just dreaming up more stuff they could do with the bandwidth provided and every industry involved had a pet technique or twelve they wanted to bring. I have no idea how the last six years or so have played out in that arena, but it's comforting to know if I go back that I don't have to keep as current to to be able break code as I would have to be to write it - or rather 'drop stuff in swimlanes and hit compile' (I kid...some). :D
*Though Ada picked up some tricks from the victors.

I hope the interface protocols are relatively flexible, cause Firewire is pretty old / outdated in the commercial PC industry.

[Gums]

Salute!

Hey Blade, a lotta stuff from the 70's. 80's.90's, and just ten years ago could use some work. Not just bus protocol.

I was fortunate to see the evolution of hdwe into sftwe and then dramatic aero improvements for the Eagle and Viper and so forth. My first digital course was in 1962 and first analog in 1963. We used punch cards for an IBM 360 down in the admin building. The analog doofer was from the "Dynasoar" program and Martin "donated " it to USAFA. So I started with Fortran, graduated to Fortran IV in 1974, and learned the op amp stuff for analog doofers in two semesters back in 1963.

The problem with new bus stuff is not speed but how to handle the speed for mission-critical stuff like arming a nuke or delivering the volts for a missile motor ignition or releasing the smart bomb from a rack and on and on. Best I know is the Viper is last jet that used an actual direct wire to the racks or launchers or the nuke. All other signals were generated locally by commands from the mux bus. As our company did the proof-of-concept demo of remote interface units for the F-16 and had a seat at the table on the SAE AE-9 cmte for developing "standards", we had a great perspective and some degree of input. I showed up about 6 or 7 years later and was hired because I had flown two very smart planes and could talk with the sfwe folks. My job was to work up the crew interface and launch algorithms for the Navy A-12 system.

Our company was steeped in interoperability and MIL-STD-1760. In 1980 we could not land some jets at a NATO base and have the bombs or missiles loaded. Connectors were different and even physical dimensions were different for racks and such. Available volts and such at store stations were all different. So our little company made $$$ integrating new stuff on old jets and old stuff on new jets.

The problem with the new bus and data transfer stuff is not speed in terms of bps, but in a safe and effetive protocol. The 1553 protocol and the 1760 requirements for using it are very harsh for critical messages and even words/bytes. The biggie with 1553 is the message gap and not bandwidth. Sucker is a "command-response" protocol, so no broadcasting critical commands "in the blind", you know, to occupant. It is not a pass the key concept, but has a god-like bus controller and that sucker will shut you down if you do not respond within "x" microsec.

So the new video stuff was neat for mass data transfer, but sucked for weapon control of critical stuff. I am sure there are some papers out there that go thru all this, but I have been away a long time.

The thing I want to see is better sfwe structure and modular features that are not tied to a single commercial company. Secondly, the code is bloated beyond belief for what it does. Look at the A-7D and F-16A and Apollo code and see what they did!!!!!!! And they did it with processors running at 1 meg/sec and with a meg of RAM or less!!! I sat in the F-16 "cockpit review cmte" in the early 80's and we negotiated for bytes!! No kidding. The EPG would trade bytes to get a new feature or delete an old one. We were working with less than a meg of RAM. So I was there the day we all voted to shitcan the "EM" display, heh heh . The IAF was there but did not have a vote. They negotiated their sfwe with GD.

enuf of old memories. The sftwe should be in the subsystems and there should be a well-protected interface with the overall system. No need to have a zillion lines of code in the main system processor/controller. Sheesh. We have been there 40 years ago.

Gums rants.....

[KamenRiderBlade]

Salute!

Hey Blade, a lotta stuff from the 70's. 80's.90's, and just ten years ago could use some work. Not just bus protocol.

I was fortunate to see the evolution of hdwe into sftwe and then dramatic aero improvements for the Eagle and Viper and so forth. My first digital course was in 1962 and first analog in 1963. We used punch cards for an IBM 360 down in the admin building. The analog doofer was from the "Dynasoar" program and Martin "donated " it to USAFA. So I started with Fortran, graduated to Fortran IV in 1974, and learned the op amp stuff for analog doofers in two semesters back in 1963.

The problem with new bus stuff is not speed but how to handle the speed for mission-critical stuff like arming a nuke or delivering the volts for a missile motor ignition or releasing the smart bomb from a rack and on and on. Best I know is the Viper is last jet that used an actual direct wire to the racks or launchers or the nuke. All other signals were generated locally by commands from the mux bus. As our company did the proof-of-concept demo of remote interface units for the F-16 and had a seat at the table on the SAE AE-9 cmte for developing "standards", we had a great perspective and some degree of input. I showed up about 6 or 7 years later and was hired because I had flown two very smart planes and could talk with the sfwe folks. My job was to work up the crew interface and launch algorithms for the Navy A-12 system.

Our company was steeped in interoperability and MIL-STD-1760. In 1980 we could not land some jets at a NATO base and have the bombs or missiles loaded. Connectors were different and even physical dimensions were different for racks and such. Available volts and such at store stations were all different. So our little company made $$$ integrating new stuff on old jets and old stuff on new jets.

The problem with the new bus and data transfer stuff is not speed in terms of bps, but in a safe and effetive protocol. The 1553 protocol and the 1760 requirements for using it are very harsh for critical messages and even words/bytes. The biggie with 1553 is the message gap and not bandwidth. Sucker is a "command-response" protocol, so no broadcasting critical commands "in the blind", you know, to occupant. It is not a pass the key concept, but has a god-like bus controller and that sucker will shut you down if you do not respond within "x" microsec.

So the new video stuff was neat for mass data transfer, but sucked for weapon control of critical stuff. I am sure there are some papers out there that go thru all this, but I have been away a long time.

The thing I want to see is better sfwe structure and modular features that are not tied to a single commercial company. Secondly, the code is bloated beyond belief for what it does. Look at the A-7D and F-16A and Apollo code and see what they did!!!!!!! And they did it with processors running at 1 meg/sec and with a meg of RAM or less!!! I sat in the F-16 "cockpit review cmte" in the early 80's and we negotiated for bytes!! No kidding. The EPG would trade bytes to get a new feature or delete an old one. We were working with less than a meg of RAM. So I was there the day we all voted to shitcan the "EM" display, heh heh . The IAF was there but did not have a vote. They negotiated their sfwe with GD.

enuf of old memories. The sftwe should be in the subsystems and there should be a well-protected interface with the overall system. No need to have a zillion lines of code in the main system processor/controller. Sheesh. We have been there 40 years ago.

Gums rants.....

I totally concur on the isolation of software parts and independence of technology from any one company.

The standards must be enforced so that we have interoperability.

[popcorn]

You have to love sfandards, must be why there are so many of them.

[neurotech]

Salute!

Hey Blade, a lotta stuff from the 70's. 80's.90's, and just ten years ago could use some work. Not just bus protocol.

I was fortunate to see the evolution of hdwe into sftwe and then dramatic aero improvements for the Eagle and Viper and so forth. My first digital course was in 1962 and first analog in 1963. We used punch cards for an IBM 360 down in the admin building. The analog doofer was from the "Dynasoar" program and Martin "donated " it to USAFA. So I started with Fortran, graduated to Fortran IV in 1974, and learned the op amp stuff for analog doofers in two semesters back in 1963.
....
enuf of old memories. The sftwe should be in the subsystems and there should be a well-protected interface with the overall system. No need to have a zillion lines of code in the main system processor/controller. Sheesh. We have been there 40 years ago.

Gums rants.....

Hey Gums,

Did any of the integration work you guys did end up on the F/A-18? The difference between the YF-17 and the F/A-18A/B is night and day. I think the F/A-18 mission software actually came from the Eagle version.

During one of the later tests with a F/A-18A+ (basically F/A-18C avionics) I got a laugh when they were loading pylons and dummy bombs onto our iron bird to make sure the hardware and software was talking to the "smart" bombs properly. It was basically hardware-in-the-loop simulation. We would fly the mission like it was a real jet.

As we transitioned to the newer "Block II" avionics on the F/A-18E/F series, the hardware performance was a lot better, but the initial software had a bunch of issues. Supposedly "solved" issues would reoccur.

One of the reasons why the F-22 was so problematic to update was that minor software glitches would shut down the CIP and airborne resets were hit and miss, and prohibited in certain cases. I've not heard of a F/A-18 having multiple AMCs shut down over a software glitch. Hopefully the F-35 open architecture will isolate software components properly.

[Gums]

Salute!

Sorry, none of our work with the F-18 in late 80's and early 90's came to fruition, although a bit of the targeting concepts for the latr JDAM did.

When I flew the F-18 sim in 1985-86, the thing was like going home to my beloved A-7D. Biggest improvementS were hands-on controls and a cosmic radar. It was better than the F-16 Block 15, as was the F-20 (that required me to fly many hours in the sim).

IMHO, the first Hornets had too many dedicated boxes ( Harpoon and HARM for two) and was not integrated as well as the Viper or F-20.

late and on the road for a few days

Gums sends...

[nht]

Salute!

Hey SgtMac!!! Remember Ada?

I watched system after system get waivers so the sftwe geeks could do fancy things with C+ and C++.

The one thing we learned was that forcing the use of one technology stack through fiat worked poorly. Especially when attempting technology injection from the commercial space.

And if the software geeks couldn't do fancy things with C then the systems wouldn't work as well.

/shrug

You can demand that everyone use Ada for avionics and flight critical systems but if developers don't want to be locked into a DoD only career expect costs to go through the roof and still struggle to get good developers. Largely this is why folks moved from Ada to C/C++ even where there was successful legacy Ada codebases.

Boeing ported everything from Ada to C for the 787 even though the 777 specifically choose Ada because it was better.

There were also some minor technical limitations of Ada but that's true of every language and not really important.

As a diehard system engineer and strong believer in interoperability, it pained me to see the demise of Ada.

Ada isn't entirely dead and interoperability does not require that everyone use the same technology stack. Systems developed in C should be fully interoperable with systems developed in Ada, C++, Java or even javascript.

Interoperability is not dependent on language selection but on ICDs and APIs.

"standards" are great, and only a few exceptions should be allowed if our various services and partners wish to have a formidable capability.

Formidable compared to what? The New Horizons flight software (C&DH) was written in C and flew to Pluto. As rigorous as avionics software is when the reset button is 4.8B kilometers away the software has to be pretty reliable.

In the end C or Ada makes little difference.

[nht]

The thing I want to see is better sfwe structure and modular features that are not tied to a single commercial company. Secondly, the code is bloated beyond belief for what it does. Look at the A-7D and F-16A and Apollo code and see what they did!!!!!!! And they did it with processors running at 1 meg/sec and with a meg of RAM or less!!!
...
enuf of old memories. The sftwe should be in the subsystems and there should be a well-protected interface with the overall system. No need to have a zillion lines of code in the main system processor/controller. Sheesh. We have been there 40 years ago.

Well Apollo cost around $49M from 1963-1969 or about $370M in 2015 dollars. The Shuttle software cost around $200M through 1985 or around $445M in 2015 dollars and while it didn't fly to the moon it did have to land. Eh. I don't think development was as lean and mean as you seem to think. Because of the hardware limitations the software had to be forced to fit at high cost. Same as today with spacecraft.

And if we looked at the software capability growth from the original F-16A software to the software running on the current block F-16s I think we'll find that the "bloat" supports using RLG INS, GPS, DTS, digital control for the engines, AN/ALR-56M RWR, HSD, etc that didn't exist in the block 1 aircraft.

What you started with a F-16A Block 1 was a daylight fighter and though hardware and SOFTWARE enhancements became an all weather all day fighter in the F-16C/D block 40/42s.

The F-35 is another huge capability jump that is as dependent on software as hardware. Just the sensor fusion portion is a likely to become a significant tactical advantage much less all the software required to support LPD/LPI comms and sensor systems, integrated EW, etc as well as improved HMI displays.

[bring_it_on]

BALTIMORE -- The future airborne capability environment (FACE) consortium is working with the F-35 Lightning II program office in anticipation that future upgrades to the aircraftâs avionics software will be open to vendors other than Lockheed Martin [LMT].
Pentagon officials, including Air Force Maj. Gen. Jeffrey Harrigian, chief of Air Force F-35 integration, have called for future block upgrades to the aircraftâs software to be bid out to other companies. That would require Lockheed Martin to at least make the software interfaces compatible with other vendors products.

Air Force acquisitions chief William LaPlante has said the service would push for open systems architectures in the Block 4 upgrades, the first capability enhancement planned after the service's variant of the aircraft goes operational in 2016. FACE is a consortium of voluntary industry members that have signed on to develop a set of technical standards for avionics and communications software. Included in requirements for future programs, the FACE standards are designed so that software will be decoupled from hardware. Lockheed Martin will not be shut out of F-35 block upgrades, even if they do carry requirements for FACE conformance. The company is a member of the consortium designing the standards and could develop technologies to them regardless of membership.

Historically, common interfaces have been required in hardware, while software is typically tied to hardware and, therefore, proprietary and stovepiped, Doug Schmidt, a professor at Vanderbilt University and the Software Engineering Institute, said at Defense Dailys 2014 open Architecture Summit.
The F-35 is both the most expensive and most technologically complex weapon every developed. Its 8 million lines of software code four times as many as the F-22 Raptor are in the process of being completed and verified by Lockheed Martin. The complexity of writing and re-checking the code is one reason that the program is infamously over budget and behind schedule. Lockheed Martin owns the intellectual property to the software and is, therefore, the only company that can do the work.
There is no mandate for any Pentagon program office to include FACE standards in their requirements documents, said Terry Carlson, assistant program officer for FACE information management at Army program executive office aviation and current chair of the FACE steering committee.
F-35 program management can dip into the library and find FACE certified conformant software products and use them if they so choose Carlson said. Each program has the choice whether to do it or not. We certain go out and educate and encourage but there is no mandate.

David Boyette, project manager for modular integrated survivability aviation science and technology at the Army Aviation & Missile Research Development and Engineering Center and a representative to FACE, said the consortium has been aggressive in its outreach efforts, preaching to message and benefits of open architecture standards in avionics to program managers throughout the Defense Department.
âm optimistic,Boyette said. We actually do have some people in F-35 now who are, lets just say, very knowledgeable about FACE. Hopefully we are be able to get some toeholds into that program as they go through their refresh cycles.
Boyette and Carlson both spoke Monday at a forum here hosted by the Open Group, which advocates for common standards and open architecture in software and information technology. FACE is a subsidiary consortium of the Open Group.
For that to happen, FACE first has to establish a third-party certification authority, which should be done in a couple months, Boyette said. Currently avionics software vendors can build to the FACE standards and measure their conformance with tools provided online by FACE. They will only be able to advertise products as FACE conformal once each technology is independently certified as such by the authority.
Each new product that adheres to the interface standards will be cataloged in ainto which program managers can delve for technologies that suit individual hardware platforms.
Boyette gave the example of a common household light bulb. From Thomas Edisons initial design to modern LED bulbs, the socket into which bulbs screw has not changed. What changes is the application powered by the interface of the bulb and the socket.
We are defining and locking down what those interfaces are for software capabilities and allowing vendors, software suppliers to innovate and bring the real flavor of their software design into that top level of the architecture while still allowing interoperability across systems, Boyette said.
Open architectures and common development standards like those FACE is promoting, would allow competition and innovation to lower the cost of developing advanced weapons like the F-35, Boyette said.
The broader idea is to bring down the cost of developing and upgrading current and future aircraft platforms because the cost curve from jets like the F-15 to the F-22 and F-35 is growing exponentially and is not sustainable, Boyette said.
As we shift from a hardware-centric world to a software-centric world, were really starting to see those costs grow exponentially higher,Boyette said. â(EURO)oeWe need to figure out ways to bring that cost curve down and make these platforms actually affordable.
Manufacturers of commercial aircraft experienced the same exponential development cost as aircraft became more technologically advanced. In response to the trend, companies like Boeing [BA] and Airbus began establishing software development standards to allow reuse across their fleets, Boyette said.
The [Boeing] 787 is really the first true example of that standards-based software reuse across platforms, he said. They were able to drastically reduce the cost of bring that system to the customer. What we want to do is do the same thing on the military side.