Follow our illustrated blog on Embedded Software Architecture

How to build a hybrid solar/wind energy harvester?

The engineering process

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)

Introduction

Let us begin with a recap. The goal of this blog is to describe how we develop:

  • a new product in a new domain,
  • with a short time-to-market, and
  • given a minimal budget.

Although our product – the “energy harvester” – is only used for illustration purposes, it is well chosen because building it, requires knowledge of three disciplines: hardware, software and mechanics. As we are (embedded) software guys there will be a focus on our discipline but, nonetheless, we have to live with the fact acknowledge that the software development process is only a part of a bigger picture: the system engineering process.

Given our special use case of creating something completely new from scratch, we want the engineering process to be:

  • iterative: that means it is a cyclic process, and
  • lean: there should not be too many sub-processes and these sub-processes should introduce only small overhead but have large benefit.

The combination of both characteristics enables us to cycle fast, yet in a structured way. This is a great feature and maps perfectly on our situation. We will be able to:

  • experiment with new technology,
  • prototype if needed,
  • release often,
  • learn form trial-and-error,
  • avoid all-or-nothing,
  • early adjust the (way too unrealistic) expectations.

Collapsed view

The figure below shows the high-level view of our engineering process.

engineering process collapsed view

There are two (collapsed) blocks:

  • development (DEV): the technical part of the project, and
  • project management (PM): follow up of the project, planning, budget, resources etc.

The goal of the PM block is twofold. On the one hand PM helps DEV by providing the necessary resources (people, tools, hardware…), by guiding decisions, by providing feedback to developers etc. On the other hand PM acts as a overseer in order to avoid that developers start to wander off track and spend time on unimportant things. The interplay between PM and DEV keeps DEV focused and PM involved. Focus is what we need, focus is what we should breathe.

Typically, project managers are not part of the engineering team. They only try to execute a project which is born out of a business case (we hope). However, in this project, we also are the project managers! We really need to do a good job in this aspect also because, well, since it’s our own time and money. Of course, this kind of dedication is always rightfully expected from professionals.

Expanded view

In the next view both DEV and PM block are expanded (see figure).

“Project Start” (PS) is a PM block. The only inputs are a high-level product description together with a budget (we do not create a whole business case as it is not relevant in this working context). The goal of PS – and this is also its output – is to initiate the project i.e. to:

  • refine the scope of the project (it must be realistic),
  • organize and allocate the team (e.g. the outsourcing of certain parts might be an option),
  • create an initial (very rough) planning.

When the project is ongoing, we call the above block “Project Update”. In essence, It is the same, but has an additional input from “Project Review”. The “Project Review” block obligates us to look back back and reconsider what we’ve done: why did our last cycle fail? Was our last design decision a good one? What can we do better? Etc.

“Project End” is reached when all development is done. This step involves industrialization, hand-over to production and closing the project. In order to realize a smooth transition from R&D to production, DEV better takes into account all special requirements from production (traceability of serial numbers and part numbers, tooling for calibration etc.).

engineering process expanded view

The DEV blocks are green in the figure and start in “System”.

“System” is responsible to

  • formalize the informal product description into system requirements,
  • build a system architecture,
  • map the system requirements on the architecture in order to verify that all requirements are covered by the architecture.

The last item is important because the mappings bring to front which requirements have to be implemented in which discipline(s): “Hardware”, “Software” and/or “Mechanics”.

For the moment we do not specify how a system requirement is realized in a discipline. E.g. the software development methodology is explained later on.

“System test” integrates the output from each discipline into a product. Initially the “product” can be a Proof-of-Concept (POC), a Proof-of-Technology (POT) or a prototype. As the project progresses, the output slowly shifts from a basic to a full featured product. The importance of testing cannot be emphasized enough as it allows for continuous improvement. Each test should verify a requirement (and thus requirements must be testable). It should be clear now that DEV is requirements driven.

One final note: if there’s delay in a green block (e.g. software is waiting for hardware) then it is always possible to go immediately to “Project Review” (these arrows are not shown in the figure). Of course, it is the task of PM to avoid too many “pending” requirements.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
Share
About rtos.be

rtos.be is a joined initiative from Gert Boddaert and Pieter Beyens.
More info: about us, our mission, contact us.

Comments

  1. David Van de Voorde says

    Well, it’s all common sense and best practices. But even put this simple, it’s obvious that most companies fail to acknowledge the necessity of some of these blocks. E.g.: make just 1 big planning, don’t review, but fire-fight the problems of the day, just assume you understand what is asked and implement it that way, let the testers invent their own requirements, etc.

    A general thought crosses my mind now: isn’t an iterative approach conflicting with the business view? Somehow, this should be reconciled.
    I mean: traditionally, business wants something, a planning is made, budget allocated, and the thing is made. Indeed, more often than not the project is cancelled or additional budget needs to be allocated, but this is probably seen as an “exception”.
    In the iterative approach, business wants something, allocates a budget, and then we “just see how far we get”. Right? This is the iterative/agile proposition.
    So, where traditionally, the PM promises to deliver everything according to budget and planning (and fails), in the iterative approach the PM simply doesn’t promise anything anymore (but succeeds to come close).

    Just food for thought in general.

    • Pieter Beyens says

      Thanks for your comment David.

      Both business and engineering need each other but, of course, their objectives and goals are not always in line e.g. business typically wants to reduce engineering costs while engineering (R&D) wants to have sufficient room to breathe. Business doesn’t really care about how or with which approach engineering (R&D) realizes a project as long as it is successful and within time and budget. Traditional or iterative, they just choose the most (cost-)effective one, no?

      Now, we all know that the traditional approach has a good chance to fail, especially in projects with several uncertainties and risks. Embedded system projects, such as our energy harvester project, are likely to fall into this category mainly because of the interaction with hardware, resource limitations and other low-level stuff. And for this reason we go for an iterative approach. Business doesn’t really have a choice because, up until now, the “success-garanteed” approach simply doesn’t exist.

      There are examples of how planning can be done in iterative approaches e.g. by using velocity tracking in scrum. Also, an iterative approach doesn’t necessarily mean that there are no deadlines anymore. This really depends on the customer. If the planning doesn’t look good then there might be the option to add resources.

      One final note: the engineering process is the global process for development and project management. It doesn’t mention how development is done in the 3 disciplines (Hardware, Software and Mechanics). This means you can actually do agile software development in the SW engineering block. This doesn’t mean though that we are going to do that… this comes later in our blog.

    • I also would like to add my 2 cents…

      It is true that common sense and best practices are often not used in embedded development. Moreover, a methodological process (supported by tools e.g.) is rarely(?) used. As a it happens, the monthly newsletter of Jack Ganssle ( cfr. http://www.ganssle.com/tem/tem228.html ) briefly talks about the methodology tools in the “embedded space”:

      “In the embedded space, UML has a zero percent market share.
      In the embedded space, the Capability Maturity Model (CMM) has a zero percent market share (other than CMM1, which is chaos). The Shlaer-Mellor process tags right along at zero percent, as does pretty much every other methodology you can name. Rational Unified Process? Zilch. Design patterns? Nada.”

      The above words are his opinion, and my colleague Pieter immediately contra-argument-ed with “What about automotive, avionics, nuclear, railway, medical, aerospace?” since those are indeed strictly regulated and do use formal process and methods. However, I think Jack Ganssle might be talking about his broad experience in the consumer electronics ’embedded space’. On the total market of embedded devices, that is a huge amount of devices made without a methodological process.

      Under these circumstances (the lack of a sound process, methods and tools), simple, manageable and elegant should work:

      – ‘Simple‘ means lightweight. It must not hinder development and must be flexible.

      – ‘Manageable‘ means controlled and iterative with reflective stop and go decision nodes.

      – ‘Elegant‘ means that all stakeholders need to see and recognize the advantages and must want to work with it.

      We chose the specific development niche of a “new product in a new domain” because

      * There is no development process that fits (yet). – A (similar) product development (in the company organization) has not been done before.

      * One will have great difficulty in coming up with a first-time accurate planning – Where is it based it on, since there are very few (task and planning) references? It is impossible to get an accurate cost and time estimation in the first cycle, but – using the proposed process – that estimate will get better every cycle. One can decide to stop or continue after each cycle: at that time, ‘Business’ will weigh potential revenue against anticipated cost. “New product in a new domain” development is a high risk activity, but the risk can be managed.

      * It positions itself, in the middle of innovative (possibly academic, but also company) research and technical product development, where you want to harvest the innovation or concept to become a new (consumer) product. This evolution can be a demanding task because of the many (technical) unknowns. In the architectural and software engineering domain, we want to share our experience and state some do-s and don’t-s, some best practices we learned and picked up along the way in our careers.

      Afterward, the ‘genetic’ product evolutions can be managed with a more traditional development process (which belongs to the culture of the organization), which potentially brings along more formal methodologies.

Speak Your Mind

*