Marc Andreesen is often credited with the line “software is eating the world.”
While I don’t know if software is “eating” the world, it’s hard to deny that it is everywhere. As the world is being filled with software-controlled devices ranging from watches to weapons systems, how can we be confident the software controlling our machines is actually safe?
Safety vs. Speed
At Tangram Flex we define “safe” software as software that has been assured from three perspectives:
- Safety — software is free from unexpected behaviors, instability, and errors.
- Security — analyzed for vulnerabilities, exposed functionality, and permissions.
- Correctness — adheres to design, is proven to work within the system context, and meets requirements.
The need for software assurance grows with society’s increasing reliance on software. Many expect that “safe” conflicts with agile software development trends. Agile development methods emphasize rapid software creation, deployment, and evolution. It seems as though safety and speed are at odds — that one must trade safety to gain speed or vice versa.
Currently the process of assuring software is extremely slow and costly. Testing for regressions, unintended behavior, instability, and system interactions takes time engineers often don’t have. On top of that, we layer in the “write, ship, repeat” priorities of current development cycles. Short timeframes make determining the safety, security, and correctness of software difficult. This approach can cause major issues with cyber-physical systems.
Safety and Speed
Can “safe” software be obtained in an environment that demands speed? We believe it can, but it will take a new breed of tools to achieve. Tools that provide the ability for engineers to examine, validate, and understand their systems without long cycles of investigation. Tools that leverage the details of system environments to reason about the safety, security, and correctness of software at each stage of development.
The tools we need to rapidly build safe software must provide visibility. At Tangram Flex we do this by breaking systems down into smaller components. This process, called decomposition, provides a visual representation of system architectures. This makes it easier to verify functionality and use model-based design approaches for systems engineering.
Componentized code allows engineers to validate each piece of software individually with automated assurance tools. Unlike traditional software testing, these types of tools examine each piece of software and generate a comprehensive record of its safety, security, and correctness. This happens before a system even passes into the test phase of engineering. As a result, errors are found earlier in the engineering cycle where they are faster and cheaper to fix, and the ultimate product is verified to be safe.
Is this really necessary?
For some systems, certain levels of risk may be acceptable. Failure to understand the software of critical systems, however, is dangerous. The typical methods of testing — hoping all potential issues are identified, patched, and updated — are not sufficient in these instances.
Our goal is not to remove the testing and certification process, but to provide tools to improve how we understand software and allow engineering teams to build confidence in their systems.
Ultimately, “safe” software can be designed and built with speed. At Tangram Flex we are working towards maturing engineering processes and tools to make safety and speed part of software development for every system.