Charge controller system architecture

Documenting architectures

Architectures are documented by views, and so that is how we proceed too. The goal of a view is to describe the system from the viewpoint of its stakeholders. Several architectural view models exist and probably the most famous one is the 4+1 model of Kruchten (see here). For the energy harvester we won’t follow a fixed model but rather introduce new views when we believe they are relevant.

Context view

The context view represents the system as a black box and was already introduced before (in this post). We only added a User Interface (UI) for:

• system information e.g. to be able to see the generated power, and
• system configuration e.g. to be able to configure different battery types.

Functional view

In this post we focus on the functional view. The functional view shows the system’s functional run-time elements. It is still high-level because all stakeholders must be able to understand it.

We are going to represent the energy harvester as a power management device in which

• power flows in and out, and in which
• at certain points ‘power management’ decisions have to be taken.

The MCU (microcontroller unit) takes a central position in our design. It measures, decides what to do and thus controls the flow of power. At this moment we can identify three decision points (see numbers in the figure above):

1. Send the wind turbine power to the load or to the batteries? The rationale behind this decision point is to allow the user to connect any wind turbine (also the bigger ones) while still be able to protect our controller against power for which our device is not spec’d. This means a user can perfectly use a high power rated wind turbine (for 99% of the time, this turbine must produce energy in the range our device is capable of handling), and at the moment the wind is getting too strong, our device will ‘disconnect’ and protect itself; the connected dump load will then be responsible for braking the wind turbine until generated power drops and our device can handle the input power again).
2. How to optimally charge the batteries? Do we need bulk, absorption or float charge mode? But also, how can we harvest energy from both sources (wind, sun) in an optimal way (e.g. MPPT)? How do we protect the batteries?
3. Do we need to send power to a device? In this case we should protect batteries as well.

Mapping the system requirements on our system architecture

We already know that all stakeholder requirements are linked to the better structured system requirements (see this post). Now we need to verify whether our system requirements are realized by our system architecture. In order to achieve this we create a relationship matrix which maps each system requirement on one or more ‘power management’ decision points (see figure below). As such we can identify which system requirements have to be fullfilled by which ‘power management’ decision. Then, when development starts, the task of implementing a decision point is clearly specified, which is exactly what we want. Of course, as our experience and domain knowledge improves, the requirements will evolve too and the mapping has to be revised and updated. From the figure it is clear that – for the moment – we ignore the housing (system enclosure).

The full model of the energy harvester can be found here.

References

Architectural Blueprints—The “4+1” View Model of Software Architecture, Kruchten

Documenting Software Architectures: Views and Beyond (2nd Edition), Clements, Bachmann, Bass, Garlan, Ivers, Little, Merson, Nord and Stafford

Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd Edition), Rozanski and Woods