In the middle of the 1990s, the common way of developing software was a heavyweight software development methodology, comprising of complete requirements documentation of design and architecture, followed by coding, integration, and finally testing based on a detailed test plan before an application was deemed production-ready. This traditional and sequential life cycle approach is often called “the Waterfall”. The whole process could easily take a couple of years. It was the general notion that this was the only way of keeping projects on schedule and out of trouble, and if projects were facing problems, the belief was that all would be well if the methodology was strictly followed.
Traditionally, the Space Industry also followed predictive models like the Waterfall model, the Compressed Waterfall Model, or the Incremental Build Model. While this approach led to approved, well-known technologies and workflows, software and software developments remained a critical aspect of every space mission.
This process can lead to very problematic situations if unforeseen situations or problems occur, or if these preconditions are not met. These situations often result in being over budget or behind schedule. Losses due to software flaws, like Mars Climate Orbiter, Ariane 5 flight 501, and Mars Polar Lander are showing the criticality of this process, especially since the complexity of the onboard software historically increases with an exponential growth rate of a factor of 10 approximately every 10 years over the last 40 years. Many space programs face the risk of cost growth and schedule delays due to software development issues.
But for new product development, the stakes are high, requirements increasing and there is a demand of delivering faster in order to beat the competition to the market. New product development is a complex endeavor, which can often be difficult to handle and challenging to see in advance what the end result will be. There is great uncertainty and unexpected things that happen along the way, which affects the scope and direction of a product development project. Therefore these projects can often be difficult to plan, and plans become obsolete soon after their creation. A more rigorous software assessment process with earlier detection and correction of software flaws could save more than a third of these costs.
This led to the rise in importance of Adaptive Models like the Spiral model or agile software development, which were earlier used only for less critical software as they promise more flexibility to change and do not require extensively defined requirements. Agile Software Development became a collective term for the new methods, which are all based on iterative and incremental development, self-organizing cross-functional teams, and rapidly responding to change.
Agile Software Development is based on an iterative life cycle and in each iteration cycle, an increment of the software is analysed, designed, built and tested. The existing result of any iteration can be delivered to the customer and further improved, changed and extended in the next iteration.
In Agile engineering, teams quickly iterate, test, and gather feedback on product design. It divides big challenges into measurable chunks of work and promises more accurate and rapid product development cycles. Teams are self-managed and work in short two-week sprints driven by user feedback. This feedback guides teams to build a product that meets user needs.
The Benefits of Agile Engineering
This method develops products quicker and reduces risk. Rather than start with a lengthy requirements phase that covers the entire span of the project, requirements are created as the team works. Requirements are specific and tied to user value. By testing features and new builds, teams verify if they are solving user problems and developing the right product.
By the end of the iteration, the software increment is fully usable. These increments build up over time to form the final product. This method allows for quick and economic reactions to changes and errors that come up throughout the process. The incremental deliveries of a “finished” product ensure that there is always a potentially useable version of the functioning product available. Halfway through the Waterfall process, there is no usable code or product ready, while the Agile methods would have 50% of the final product finished and usable. This is related directly to when testing is performed in the process. It emphasizes the importance of testing continually throughout the process, as it allows for proactive measures when it comes to errors and software bugs.
Agile engineering saves companies not only time but also money in the long run. The agile method in product development has a higher startup time and initial cost, but the cost per final product is low. Plus, the end product is shaped by market demands, ultimately yielding greater profit.
Another benefit of agile engineering is that it encourages teams to fail quickly. By failing faster, teams learn and improve at a faster pace than those that do not. Learning from failure through prototypes helps companies quickly build better products. By validating assumptions and collecting data, these products are made in a more accurate, evidential way.
Agile engineering in the Aerospace and Defense
Agile has grown beyond its roots as a software development approach. More and more, all engineering disciplines are adopting the agile method with positive results. And it has shown great promise for aerospace and defense companies willing to abandon their traditional thinking toward product development.
Many have moved toward integrated engineering teams, combining the software, electrical, and mechanical disciplines where the systems interact
One of the earlier successful examples reported has been was the student satellite project, Munich Orbital Verification Experiment II (MOVE-II) at the Technical University of Munich (TUM) where the concept of agile software development was successfully applied to develop the software of the onboard computer within a few months. “The software operating on our satellite can be split into different groups using their purpose or the existing subsystems of the satellite, namely: Structure (solar panel and antenna deployment software), Thermal (temperature monitoring software), Attitude Determination and Control Software, Communications software, Electrical Power System (electrical power control and analysis software), Payload software and Command and Data Handling software.”
Following the subsystem decomposition, the requirements for every software component had to be defined. Following the agile software development approach, these requirements were then successively specified in more detail to reduce the number of possible interpretations as well as changed and adjusted if necessary.”
“This enabled us to create clearly defined interfaces between the different software components and subsystems and allowed us to develop independently until we integrated the software on the satellite, write A. Lill, D. Messmann, M. Langer from the Technical University of Munich.
After the collection of requirements, the first goal was to implement a very first version of all the software components in a few days. The so-created version constituted the Minimum Viable Product of our software and therefore included the most important functionality and interfaces and allowed us to run it together with the other components on the hardware. After the implementation of the Minimum Viable Product, there has always been an artifact that could be tested and incrementally changed. This means that the basic functionality can be improved and extended and that additional features can be added.
Agile Engineering for Hardware development
Agile engineering is a popular process in software development, but few hardware teams apply these practices to develop physical products. The principles, however, are broadly applicable. Agile ideas are based on how people and organizations work best. In any project that faces uncertainty, complexity, volatility and risk, there is a place for agile practices and principles.
Agile methods require modification to support the needs of hardware products where making changes are costly, partial products are difficult to test with real customers and definitions must be frozen for production.
However, with digital fabrication tools such as mills, laser cutters, and 3D printers, hardware engineers can now develop ideas while concurrently testing them with users. Key benefits of this method include:
- Continuous collection of feedback from customers means that designs are tracking with customer needs.
- The interplay between design, engineering, manufacturing, and marketing allows teams to understand each other’s needs and challenges better.
- Each iteration gives you a physical prototype to hold and discuss. Kinesthetic learners, experiential learners, non-technical people in a technical meeting, people new to the subject matter—they will all learn from holding and discussing an actual prototype.
- Testing the physical prototype helps you identify and solve problems.
- More, quicker, and cheaper iterations mean that a higher number of possible solution paths can be explored.
- Continuous testing means that engineering risks are exposed throughout the process.
Agile Aerospace success stories
The Johns Hopkins CubeSat Case shows how Agile Systems Engineering concepts were used in the Multi-Mission Bus Demonstrator (MMBD) project, designing and developing two small satellites at The Johns Hopkins University Applied Physics Lab.
Another example of use of Agile practices in hardware development is the Wikispeed modular and road-safety-legal automobile, of which a functional prototype was built that travels 100 miles per gallon or 2.35 L/100km. Wikispeed is composed of self-organized teams that complete a new iteration of innovation during one-week Sprints . There were first 44 volunteers involved, in four different countries, but have now grown to 140 of part-time working volunteers. These self-organized teams use Scrum to re-evaluate each part of the car during each Sprint, as well as deciding on what highest priority features to work on next
Agile Engineering for Aerospace Hardware
Agile aerospace is a philosophy of spacecraft development that encourages rapid iteration, where the aim is to make small improvements to every spacecraft design instead of exhaustively trying to perfect each one on the first try. The goal of this approach is to continue to optimize spacecraft architecture through an evolution of capabilities.
Agile product development enables aerospace manufacturers to mature complex programs faster by allowing them to rapidly meet requirements in every engineering sprint – continually testing, verifying and validating. At the end of the sprint, teams will be able to confirm what they already tested virtually. Using an agile engineering approach, new capabilities can be easily incorporated at any point in the development process to adapt to new market requirements.
Latécoère, a French aircraft company, deployed agile to dramatically reduce the amount of time it took to design and build a new aircraft door. The company’s goal was to cut development time from four years to two years. But with agile, it did even better than that—designing and building a door in just 18 months.
We had decided to go for the agile methodology because the market requires [companies] to inject breakthroughs in a shorter time than what we could reach using the conventional methodology. As an example, it takes four years, approximately, to fully develop a door [for an aircraft] starting from scratch; and if we were to follow that schedule, we wouldn’t meet the market milestones for the next aircraft development. The main leadership skill that we have to show and that we have to leverage when we go through this agile journey is twofold. The first one is trust, and the second one is empowerment. You have to refrain from being intrusive, of micromanaging the team, said Serge Bérenger, Latécoère’s senior vice president of innovation and research & technology,
Planet labs
Planet Labs designs, builds, and operates large constellations of nanosatellites. Each individual satellite is 3U form factor (10cm x 10cm x 30cm). The spacecraft payload is an optical system and camera, capable of capturing imagery at 3-5 meter Ground Sample Distance (GSD). Planet Labs satellites are designed to be frequently updated and replaced; each satellite has an expected operational lifetime of 3 years.
Planet Labs uses an “agile aerospace” approach to technology development, using rapid iterative design and frequent testing in space in order to continually deploy improved spacecraft and payloads. At Planet, this means frequently releasing new spacecraft designs, testing them in space, and making changes based on the results.
We’ve taken an agile aerospace approach since 2012, and have completed 14 major iterations of the Dove spacecraft design with new generations being released at a steady rate. Planet Labs has launched three versions of its optical system, Planet Scope 0, Planet Scope 1, and Planet Scope 2. Planet Labs’ satellite constellations operate in a constant monitoring mode. Individual satellites are not tasked, they remain nadir pointing and they continuously capture imagery of the sunlit portion of the earth’s surface. Planet Labs has developed its own network of ground stations to ensure efficient satellite operations and successful downlink of imagery.
Getting our first satellites into space quickly—even if they were far from perfect—enabled us to step through the regulatory and launch integration processes, develop our constellation management software, and learn some hard lessons about the challenges of space optical systems before changes became too costly. We were able to bring prospective customers into the loop as well and received feedback on actual imagery captured by our early satellites that guided our engineering focus in subsequent years.
While we’ve reaped the benefits of this philosophy, it’s worth noting that it does not make sense to apply it to just any project. Taking an agile aerospace approach imposes constraints on how a spacecraft is designed, manufactured, and operated, and we’ve found that it goes hand in hand with a large constellation approach to realizing a mission.
Rapid iteration and testing in space are key to agile aerospace but are simply not feasible unless the individual satellites are inexpensive to both manufacture and launch. Launches are often shared between satellites from multiple companies, and to keep costs low, satellites must be small and lightweight. To do that, we miniaturize traditional satellite parts to fit inside our shoebox-sized sats—so while our satellites are smaller, they still possess much of the functionality of larger satellites. They should also be available to purchase on short notice, as it’s not possible to build a new spacecraft in three months if the parts take a year to acquire (as is typical with aerospace-grade components).
Fortunately, the consumer electronics industry has been driving the development of highly capable, inexpensive, miniaturized, and fairly reliable components for decades. Adoption of this commercial-off-the-shelf (COTS) parts in lieu of larger, more expensive, less capable aerospace-grade components have enabled us to develop a satellite that’s inexpensive to both manufacture and launch in a short time frame.
All that said, agile aerospace has its own set of challenges. In a highly miniaturized design, there is likely no room for redundancy, meaning that if a single critical component fails there is typically not a spare to take its place, which often results in the need to retire the satellite from imaging. This, coupled with the somewhat lower reliability of COTS components relative to their aerospace-grade counterparts, means that the individual satellites are going to be less reliable and possess a shorter lifetime than, say, a $500M bus-sized NASA spacecraft. So then the question becomes, how do we still manage to meet high standards of image quality and coverage?
While our sats aren’t as reliable as traditional, larger satellites, we fly them as part of a large constellation that creates redundancy across the fleet, removing any risk to reliability. We invest heavily in developing intelligent constellation management software that can detect and react to problems with individual satellites, and reposition them as needed to fill in gaps in coverage. The end result is a constellation that reliably produces a continuous stream of high-quality Earth imagery. It’s composed of around 100 spacecraft that are continually being retired and safely de-orbited—being replaced with the latest versions as they’re released using the most up-to-date technology possible.
“[At Planet,] we take a more hands-on testing approach [to aerospace], which is quite different from the rest of the aerospace sector, which takes a hardcore analytical approach to finding problems and risks in satellite design,” Marshall explained in his 2015 talk at Stanford University. “[Traditional] satellites have done a tremendous service in helping us to understand the planet so far … But if you want to put 150 satellites into space, this model doesn’t really work.”
Hybrid Approaches
However, it is not common to implement this type of iterative approach in engineering, mechanical and electrical design projects. Agile is all about adaptability to frequent changes, so it requires experience and quick decision-making ability to accept some changes and postpone other changes for the next sprint. The agile methodology does not work well if the client or the team does not understand agile methodology and could not keep up with the fast-paced environment. Agile is considered a risk for a team which lacks experience.
Many organizations are now employing ‘hybrid’ methodologies that are designed according to similar principles – combining the strengths of both waterfall and agile into one approach. The main aim of the hybrid methodology is to enable teams to define requirements and adapt to changing requirements through continuous feedback and delivery. The hybrid method retains the clarity and tracking system of waterfall method, while embracing the adaptability and flexibility of agile.
References and Resources also include:
https://agileforhardware.org/wp-content/uploads/2018/07/An-Intro-to-MAHD-Ebook-Final-7_25_18.pdf