Introduction As embedded software engineers, we might not have an in-depth understanding of all electronic charge movements through semiconductor circuits, but at least we’re able to reason about hardware design at a concept level. In a previous post we introduced the energy harvester’s Power Management concept. We now elaborate on this and propose our initial […]
Simple Platform Abstraction
What When prototyping, it is uncertain and sometimes even unlikely that the experimentation platform will be the basis of the final industrialized product. Therefor, it is good software developer workmanship to protect the logic development from change with regard to board, processor and real-time operating system, if and whenever possible. A platform abstraction – in […]
The relay
Introduction A relay – in this context – is an electronic switch and can be controlled by micro-controller logic. There are different types of relays, with different pin configurations. A 4-pin relay can be OFF (not conducting current) or ON (conducting current): 2 pins are powering and thus controlling the relay and the other 2 […]
Some basic hands-on experience with a dump load
Introduction The dump load (already introduced here) is used to burn the excess energy of our battery charger. The excess is typically generated by the wind turbine in windy conditions. In contrast with solar energy, the battery charger must accept wind energy in order to protect the wind turbine. For that reason the dump load […]
Development: a mixed top-down, bottom-up approach
Introduction In a previous post we proposed our RTOS engineering process: a lean and iterative process, which cycles between project management and development (see Figure). In this post we describe our development approach that can mitigate the risks and uncertainties of developing a new product in a new domain. But before we come to that, we introduce the two […]
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 […]
From stakeholder to system requirements
System requirements and their organization Given our stakeholder requirements and some basic domain knowledge, we can now initiate the system requirements. Instead of extending the rather informal and unstructured stakeholder requirements, we prefer to start with a brand new set of requirements which is organized in a hierarchical structure (divide and conquer!) in which: the […]
Domain knowledge and application information
Introduction Building the right product requires customer input and domain knowledge. Building the product right requires a technical expertise and (possibly) a development process. In this post we focus on improving our domain knowledge. As mentioned in one of our previous blog articles, the more domain knowledge we acquire, the better we can define the […]
Stakeholder requirements
Introduction End-users, developers, testers, production, project managers, business, sales… they all have their interest in the system and are called stakeholders. At first, it is the task of the system architect to collect those interests (or concerns as recent literature suggests [ref]) and to resolve (potential) conflicts. Communication is key since stakeholders do not necessarily […]

Recent Comments