The rise of the number of commercial space flights in the last decade has prompted renewed interest in engineering careers, including EE, ME, CS, and software programmers-engineers. Highlighting the growing interest on the software side of space and similar mission-critical applications was an ecosystem talk during the Arm DevSummit.
Keenan Johnson, Head of Robotics Software Engineering at Bedrock Ocean Exploration, talked about his experience with software development at SpaceX, NASA, and on electronic aircraft systems and deep-sea drones. One of the biggest challenges he saw in developing software for the space industry stemmed from unreliability and the high failure rate of applications in the consumer market. Most people simply don’t trust software to work all of the time. While a software failure in most consumer apps is inconvenient, it’s often fixed by simply rebooting the computer, cell phone, or other devices.
Such immediate fixes are fine if all that might be lost is the last web page you were viewing or a bit of text or even data. But in mission-critical applications like aerospace, rebooting is seldom an option. The consequence of software failure in such situations is very high – even life-threatening.
Arm DevSummit, Keenan Johnson
|Example of code for a hardware bracket.|
Johnson gave one example of why modern software development tools and processes are part of the problem. Consider the case where a software developer needs to code a mechanical hardware part like a simple bracket. Basically, the task is to create the software equivalent of a hardware bracket, i.e., an angle brace. According to Johnson, the challenge of modern software is that every company creates its own bracket function and each one might be slightly different. In a large project, all of these different but similarly named bracket functions might be integrated together into one large program as drivers in different operating systems and for a variety of applications.
The problem is that most consumer companies cannot afford to incur the cost and time involved in writing all software programs from scratch, so they try to use software functions and libraries from other places. Will they all work together? While testing and verification might reveal problems, that phase of the development cycle is often reduced or cut due to budget and time constraints.
One might be tempted to say that open-source software would solve this problem for aerospace applications as the code is often good and designed for reuse. But as Johnson pointed out in the Question and Answer session, open-source libraries are used very seldom for mission-critical software applications as in SpaceX missions. Code for such projects must usually be written all in-house to ensure reliability and the absence of hidden malware or bad code. The only notable exception of open source usages is the adoption of the Linux operating system kernel by SpaceX, a practice not yet adopted by traditional space companies.
Otherwise, the tools used by the SpaceX team was C/C++ based. The user interfaces for the ground station and Crew Dragon spacecraft run on Chromium, said Johnson. Chromium is Google's open-source foundation for the Chrome web browser. The use of such open-source code does raise the question of the reliability of web-based technology in general.
SpaceX is famous for another reason, namely, its use of social media tools like Reddit. There is at least one Reddit “ask me anything” (AMA) channel hosted by a few of the SpaceX team members. These members helped develop and deploy software that flew Dragon and powered the touchscreen displays on the human spaceflight demonstration mission (aka Crew Demo-2). These members freely answer any reasonable questions about Dragon, software, and working at SpaceX.
SpaceX AMA on Reddit.
Returning to the question of the challenges faced in developing software for space applications, Johnson commented on his vision of the future for programming languages in space. He sees humans are highly graphically oriented. Nobody has yet created a compelling graphical programming interface. As future applications continue to grow in complexity, the need for conceptualization as part of the software development process will only increase.
In his experience, Labview is the only graphical programming language that has had some success. Unfortunately, it is a proprietary, closed environment.
For now, he conceded that software developers in aerospace can’t go wrong with C and C++ environments. Python could be used for some applications, but it isn’t well suited for real-time applications.
Another place Johnson might look to find progress in the reuse, integration, and even testing of aerospace software would be to see how these tasks on done in the highly complex hardware semiconductor chip and intellectual property space. But perhaps that’s a subject for another time.
John Blyler is a Design News senior editor, covering the electronics and advanced manufacturing spaces. With a BS in Engineering Physics and an MS in Electrical Engineering, he has years of hardware-software-network systems experience as an editor and engineer within the advanced manufacturing, IoT and semiconductor industries. John has co-authored books related to system engineering and electronics for IEEE, Wiley, and Elsevier.