(c) Bruce Powel Douglass, Ph.D. 2019

Jul 8

Agile Firmware development

4 comments

Is Agile methodology suitable for Firmware development? More generally, when Hardware and Software must be co-developed and manufactured, would Agile still be a good approach for the software development? Perhaps, Firmware can still be decomposed into an OTP (One Time Programmable) piece + a piece that can be updated "over the air", in which case the latter could still follow Agile. But what has been your experience with real Firmware projects? Thanks

In short, yes, absolutely, but not in exactly the same way as true software. There is a spectrum from hardwired electro-mechanical systems to non-embedded software, and the axis of this distinction is ease of modification. The more you add physical production elements, the more effort and time should be devoted to analysis and design before committing to physical manufacture. This means that the greater the percentage of physical hardware, the more effort must be taken in verification before manufacture using heavy-weight design and analysis.

 

For example, released software can be fixed with a software patch, often OTA. Physical hardware requires physical processes for updates; thus the rules for agile software, which ultimately assume infinite malleability, don't apply well to electronic & mechanical hardware. In practical terms, this means that more "traditional" processes of heavy-design-and-analysis-upfront (HDAUF) make more sense for HW than for SW because the cost of refactoring and correction are far higher.

 

However, this is a spectrum, so truth is somewhere in the middle, depending on the actual properties of the system under development. Most systems I deal with fall somewhere on the spectrum, but exactly where can vary quite a bit.

 

Ok, let's get practical now. Agile methods can easily be applied to HW but to be most effective, they may be applied differently than with software. Early simulation, breadboarding, hand-built electronics, for example, plays a more important role in agile HW development than in SW, because it is easier and less costly to regenerate the software from the design than for HW. OTP HW should be developed using HDAUF while run-time reprogrammable systems can be more incrementally developed.

 

The relevant things to consider, I believe, are:

  • What is the cost of creating the released product, both design cost and manufacturing cost ? (also known as non-recurring and recurring cost)

  • What is the lead time for producing the product? (many physical systems have long lead times)

  • What is the cost of refactoring the design and implementation?

  • What is the cost of defect repair in a released product or in the released facet*?

  • What is the likelihood of defects in the different engineering disciplines? (best to use historical data here)

  • How will updates to released products be managed? (OTA, service calls, recalls, etc)

to find the optimal mix of incremental and traditional approaches that minimizes overall product cost and maximizes product quality. You must look at the specific properties of the elements and engineering disciplines involved to answer the question. And they vary from business to business and from product to product.

 

It is also possible to mix traditional development for HW with agile development of the SW (which, I of course, is your actual question); in fact, this is very common and, for many, a preferred approach. I do this all the time.

 

Remember that Agile doesn't mean "rigorously following Guru X" but rather "adapting your approach to provide the most value with respect to the success of the product depending on the nature of the business environment and the product".

 

Anyway, that's what I think.

 

Anyone else want to weigh in?

 

- b

 

*facet is a term I use for the portion of a product specific to an engineering discipline; so we have software, electronic, mechanical, hydraulic, pneumatic, (and so on) facets, which are the contributions each of those disciplines make to the overall product.

Thank you for the comprehensive response, it was very valuable to me. Normally, in co-developed hardware and software for critical applications (my current field of work is aerospace) there are project reviews that typically follow a waterfall/V-model life cycle. We are a small embedded software team that is trying hard to develop software using SCRUM agile methodology. What would be your strategy to harmonize HW HDAUF development (e.g. V-model/waterfall), embedded SW development using SCRUM and project reviews (and also hw/sw release s) following a V-model/waterfall lyfe cycle? Thank you very much for your time.

Short answer: I would plan out the increments and their mission (which includes not only functionality but also targeted platforms (HW)) and adjust to support the evolving HW capability and maturity. This means that HW moves from simulation, to breadboard, to wire wrap, to 1st cut boards to final factory boards, and software should match pace, providing not only deliverable functionality but also additional HW test/verification support software to aid in the HW development. All of this is planned in the set of iterations.

Thanks a lot for the response! I do agree with your approach. Something that I forgot to mention. Altough the current project targets the development of AOCS actuactors products to fly in LEO, the development philosophy is "new space". That means we qualify EEE parts from automotive grade under representative space environment conditions. That also means we have assess to MCU discovery boards even before the HW simulation. That said, for particular target firmware features, like e.g. over the air sw patch capability, cooperative scheluler, device drivers, we can do it independently from the hw maturity evolution. Once the hw breadboard is assembled and comissioned we will strongly consider your approach. Thanks again!

New Posts
  • I like the model organization structure that Harmony aMBSE is suggesting in Agile System Engineering, chapter 3.3 Organize Your Models Like It Matters. I have one question though: What is the reason that the Deployment View Pkg is in the subsystem models? That means that there is no holistic Deployment View (sometimes also called "technical context"), because the information is split over different subsystem models, right? I believe this view is especially important to integration and network guys. I also think that it is not a good idea to put a common Deployment View in the SE model as you do not want the dependencies to the physical interface packages there. I am wondering, does it make sense to keep a "complete" Deployment Package in the shared model? Please let me know what you think.
  • Dear Bruce, in Harmony ESW process you added User Stories as an additional starting point to the Microcycle. I think User Stories are usually used to describe the "problem" or "expectation" of a stakeholder regarding the "product". It is maybe something like a high level requirements elicitation approach, which differs from Use Cases. What are your experiences and best practices to work with User Stories (e.g. high level approach) and Use Cases (e.g. detailed approach) regarding high-fidelity modelling and requirements refinement? Do you have a taxonomy regarding requirements, use cases, user stories and modelling? Thank you. Best regards, Matthias
  • This forum is intended for discussions about processes and methods, focusing on agile and lean methods for systems engineering and embedded software development.