Finally, we are almost there. Our first product – a joint development result of cooperation between IACS and RTOS.BE – is about to be commercialized. The Energy2Switch is a DC switch board with 2 channels rated up to 50V and 40A. Continuous power is limited at 1500W per channel, which boils down to 40A @ […]
The energy harvester is ready for iteration 3
Iteration 2 overview Wind power to dump load switching has been the main topic of iteration 2. In our system design we also call this Power Management Decision 1 (PMD1). PMD1 should realize several system requirements and, because we have an energy harvester model in Enterprise Architect, this list of requirements can easily be generated […]
Investigating the Wind-turbine to dump load switching – part 3, other alternatives
An alternative relay we have not looked at, until now, is the latching or bistable relay. This kind of relay will only use power when changing state from open to close or from close to open. Also, it keeps its last state. Those properties could be interesting, because one of the problems we face in […]
Energy harverster logic hardware design
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 […]
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 […]
Our at-first-sight trivial product: a hybrid solar/wind energy harvester (aka battery charger)
As long as we are going to build something, it should be awesome, hip and cool. It would have something to do with renewable energy for example. Yes, we are going green, because green is cool! Bugger if it already exists! As this is for demonstration purposes only, we don’t care. We appreciate the free […]
Recent Comments