“Here at the coal-face, things are real” my old boss used to say. While we were building a coal fired power station (Medupi), he was referring more to the idea of “real work,” as opposed to the work, according to him, our bosses did (“fiddle with PowerPoint”).

The phrase “coal-face” (a dictionary term would you believe) was probably coined when coal was King, back when the world was young, but the world has changed. Not only is coal set to give up its crown (albeit too slowly to halt climate change), but the world of work is also vastly different to the old days. The “solar-face” seems, somehow, to be a more fitting description of a distributed, very fluid, very complex world of work. Solar = new, coal = old.

One of the big changes in the world of work between then and now, I would suggest, is a shift to more widespread adoption of “Systems Thinking.” When coal was King, the world was less complex, less non-linear, less interconnected. In the solar era, the new world, thinking more broadly is increasingly required of the modern “knowledge worker.”

Recently I had the awesome opportunity of being involved in a project that brought together the worlds of solar energy (my domain of interest) and Systems Engineering (my favoured flavour of Systems Thinking), in interesting ways. SANZAF, an NGO I’ve worked with for years, wanted to provide electricity to a mosque and small community centre that it supports in KwaThema on the East side of Johannesburg. The facility, despite being surrounded by semi-formal dwellings which have been electrified through connection to the national grid, had no grid connection (making this an off-grid project). The facility also wanted hot water, something which it had never had in its 20 odd years of existence.

I’m not going to go into the details of the project, which is well documented here by one of the partners in the project, because I want to focus on the lessons learnt from a System’s Engineering perspective. However, I do want to note that the project had a fairly unique structure (my design, for better or for worse), with the partners including industry (ZPE), the local student Engineers Without Borders chapter, a Wits student working on the project in fulfilment of his industry work requirements for his degree, and a welcoming client. This structure deserves its own post really!

Domain-specific Systems Engineers:

This project strongly reinforced my view that domain-specific System Engineers are better than System Engineers who have not spent considerable time in a domain. This was made clear in a few ways. Firstly, and rather unfortunately, the solar PV panels were stolen a few weeks after commissioning. Theft risk was something that was raised during the (very rushed) design process but went largely untreated (and its probability of occurring not truly appreciated). A System Engineer who regularly does small, off-grid solar projects in peri-urban South African communities, would have given far more thought to theft risk. They would also have a grasp of the range of solutions to theft risk that have been implemented in other projects. In short, the domain experience of the System Engineer on the project would have gone a long way to prevent theft of the panels.

Secondly, the client (the NGO) had very little idea of what to expect from a “solar energy solution.” This is no reflection on them, as I probably have less of an appreciation of what goes into running an NGO than they have of solar PV systems. Requests from the client for the facility to be “completely sustainable and off-grid” relate directly to the core System Engineering activity of upfront requirements definition. A good Systems Engineer will push to clarify this requirement of “complete sustainability.” A good System Engineer with solar (domain) experience however, is far better equipped to help the client navigate the refining of this requirement. Fortunately, on this project we had solar experience on the team, and so this was achieved.

The team was able, for example, to immediately explore the idea (with the client) that being off-grid is very sub-optimal, and that a grid connection really should be pursued vigorously from a cost point of view. The team was also able to quickly help the client understand (using fairly accurate numbers) what could be achieved (e.g. how many lights and appliances could be run) for different levels of investment. Off-grid PV systems, even those with battery storage, are inherently difficult to predict from a performance perspective (at least for instantaneous or small timeframes, depending as they do on sunshine) and so it is invaluable to have a Systems Engineer who is familiar with these dynamics to help define the client’s requirements.

Using Data Visualisation and Games!

The last point in the section above touches on something I think is fundamental to good Systems Engineering: helping the client explore the design space in order to better define their requirements (and hence meet expectations). In this project, it was necessary to help the client understand, for example, that adding extra PV panels might increase energy collection, but the energy collected in summer and in winters still differs, so you are limited in winter (when compared to summer).

Another example: helping the client to appreciate that a prolonged period of rain and cloud always has a chance, no matter how oversized the off-grid system, of resulting in failure to provide the required power.

This exploration of the design space (i.e. the system’s performance for different levels of investment and cost, subject to various constraints) is an essential System Engineering function. Doing so, I think, could be vastly aided by using concepts like data visualisation and simulation games.

Great looking graphs, carefully designed, could really shift the System’s Engineer’s ability to communicate the concepts behind key trade-offs to stakeholders. For example, solar system performance (energy produced) is predicted using different “probability of exceedances11 See discussion in (Dobos and Gilman, 2012.),” so exploring which type of graphic might be most effective in communicating the difference in price between a P50 and a P90 system is an important exercise.

A key idea that I want to propose here is there may be certain visualisations that just work very well for certain domains (like small scale, off-grid solar PV installation), and identifying which visualisations these are will benefit all projects in that domain. This is effectively finding the best visualisations for a domain (other domains come to mind: heavy vehicle design, drone design etc.)

Recently for example, I saw the graphic below from the Economist. With the World Cup in full swing, I wondered if this type of visualisation might help goal keepers in penalty shoot outs: would they save more penalties if they could use this type of graphic to remember which striker prefers which placement?

Figure 2: Football penalties. The Economist

Working towards the same end, simple computer games may also improve the ability of System Engineers to help clients understand their own requirements. I recently found this “game” on why systems seem stuck, and change seems to happen all at once. The use of hills to represent growth/death was super useful for me, and I starting to think if perhaps a similar approach might be used in the solar space. We could design a game where a user can change their load profile (put on another fridge, add a heater), and change the number of panels and batteries, and see the resulting cost and power provided. Nicky Case, the person that built this game, has built many others based on the same ideas, and it’s worth exploring them here and here (warning: this is a rabbit hole!).

Another fantastic example of a game that can be used to help stakeholders understand the complexities of system design, is Mini Metro. It’s a super game I’ve been playing for a while, and a nice explanation as to why it’s potentially so useful as a “communication tool” can be found on the blog of Jarret Walker, Human Transit, over here.

The use of better data visualisations and computer (phone) games ties neatly back to my first point about domain-specific System Engineers: truly understanding a domain is probably necessary (although not sufficient) to build the tools required to help clearly define client requirements.

The value of good models in System Engineering

The client for this project also wanted to add hot water to the mosque. The primary solution in the client’s mind was actually not a solar geyser, but rather a gas geyser. This is because they had recently installed a gas stove (LPG), which had proven very successful from a cooking perspective, and they had also heard that a gas geyser provides hot water on demand (as opposed to a solar geyser, which does not provide hot water all the time). Given the client’s stated intention of reducing long term operating costs, we were obliged to help them explore the differences in lifecycle cost between the solar and gas water heating options.

As an engineering team, we considered 3 main system architectures: solar geyser only, gas geyser only, and finally a hybrid system. We had established an estimated water usage profile (based on the dynamics of the mosque’s prayer times22 The mosque presented an interesting case in electricity and water demand. Being off-grid, it cannot rely on a municipal (grid) supply. Being a mosque, the demand profiles are fairly unique: the fajr salaah, or early morning prayer, occurs between 4 and 6am. This time frame is just before the sun rises, which is the worst time for a solar system (the system, both water and electricity supply, has been without input energy for the longest period at this time). Furthermore, Esha salaah, the late night prayer, is between 7 and 9pm. This period is not as stressful on the solar system (the load here does compound the problem for the next morning), but both these periods are also very cold during winter. The resulting unique profiling introduces some question about optimising the system performance, to be explored perhaps in another post!etc.). Based on the complete set of client requirements, it was possible to select the best architecture (the hybrid) using only high-level analysis. However, I was left wondering if a more robust analysis could have been done in a similar amount of time, to give us a higher level of certainty in our decision.

So just for kicks, I opened up SAM (from NREL) and started to play with the solar water heating modelling capability it provides. I quickly realised that it was easy to model the solar only architecture (using SAM), a bit trickier to model the geyser only solution (using a spreadsheet but made difficult by needing to build the finance calcs already embedded in SAM), but it was rather more difficult to model the hybrid solution. Further down the rabbit hole I went, by exploring how difficult it would be to use the open source code for SAM to do this analysis. I found SAM’s Github repository quickly enough, and located the technical manual describing how SAM models the underlying physics of water heating fairly easily too, but that’s where I came up short.

I probably came up short for a variety of reasons: I am not particularly good at thermodynamics, and even if I did get the thermos, I don’t understand the software engineering (coding, architecture etc.) that underpins a complex piece of software like SAM. (yup, us “industrial and system” engineers are pretty useless 😊)

But I also gave up on this exercise for another reason: even if I were great at thermodynamics, and a super software developer, I had the feeling that based on the documentation available for SAM, I would still have to spend many, many hours building the hybrid model. Let me be clear, I think SAM is an excellent product (God bless America for funding their National Laboratories) and the documentation some of the best I’ve seen as a lay-man, but I did get the feeling that I would have to be very much a specialist in multiple areas in order to build a gas-solar hybrid water heating model (which gives performance in both water terms and costs).

I could very easily be wrong about this, and would love to hear a counter view.

The level of specialisation required (thermos + software + finance) I think goes even beyond what a domain specific System Engineer would be able to quickly muster up (and by domain specific, I’m talking about a fairly specialised person already: she would be a System Engineer who does off-grid, water heating in peri-urban South African communities as a day job). And I think this speaks to the value of good models in Systems Engineering. Let me explain a bit further:

While the question of hybrid gas-solar water heating may not be a common one33 But surprisingly, here is a commercial unit from Bosch that facilitates solar and gas water heating. (and hence SAM has not extended the functionality to include that), I think having clear, well-documented, and easily extendable models in the water heating domain will allow fairly quick resolution to the hybrid question. So good models, would allow System Engineers to efficiently solve new types of questions in their specific domain (and are therefore incredibly valuable).

What is a good model though? That’s an important question I’m not going to try to answer here, or perhaps ever, because I don’t think I’m qualified to answer that (I can contribute though). However I do think that System Engineers, because of their very role in integrating design work between specialists, are ideally suited to ensuring the development and maintenance of good models within their specific domains. More about this another time!

Slow engineering – waste or valuable?

The theft of the solar panels within a few weeks of installation on this project left me with many thoughts, but also a nagging feeling: perhaps we should have gone slower.

Now, while the client had good reasons for rushing this particular project through design, it’s not the first time I’ve been left feeling like we executed a “frenzied” project. That we did not stop to smell the flowers, or even to breathe, and definitely not to think.

So I googled “slow engineering” and found a few interesting links: Bernie Carlson, a Professor at the University of Virginia and interestingly, Chair of the Engineering and Society Department there wrote this piece for Forbes. He references another informative piece by Ed Quesenberry. Mirroring the slow food movement (which has many good criticisms in my view), slow engineering leaves me conflicted. Engineering is unfortunately ruled by the “tyranny of the time sheet” and stopping to “smell the roses” costs money. System Engineering has as a key pillar the idea that upfront work may cost more initially but investing in it saves many times more money later on in a project lifecycle. In the case of System Engineering, I think this case has been proven many times over. However, for the case of “slow engineering,” it is less clear, because slow engineering (at least the brand I have in my mind) advocates something different.

While upfront work in System Engineering focuses on getting the requirements right, understanding the problem thoroughly, understanding the trade-offs in the architecture etc., the brand of slow engineering I have in mind goes beyond that. Beyond the upfront work, to “smelling the roses.”

I keep wondering, what if engineering projects made time (in the dreaded engineering schedule) for “idleness”? What if a project was completely unrushed? Where, even if felt we understood theproblem and have the requirements defined well etc., we just hang around the project, doing nothing but breathing and thinking.

Clearly this is would be a luxury, affordable perhaps to only the elite. But I can’t shake the feeling that perhaps it might deliver many times more “value” per Rand /dollar than the traditional approach.

In this particular project (let’s ignore the real circumstances for a blissful moment), idleness might mean simply going to site to spend the day there, with no plan, no intention to do any work, not to understand any user, to interview anyone, but simply to soak the project in. And think. Perhaps I would have better understand that solar panels apparently contain a powder that poor drug addicts consume.

I think, at the very least, it’s worth exploring the idea of slow engineering. I’m not suggesting inefficiency, but rather a “less haste, more speed/value” approach. There may be ways to dilute some of it’s negativities (for example, if such projects published their experiences openly, it might allow other projects without the luxury to learn from the extra value gained).

This may prove an impossible concept to measure (unlike the value offered by System Engineering), but it would be a great day if we were able to “soak in the sun” at the solar-face.

Report from the “solar-face”

Domain-specific Systems Engineers:

Using Data Visualisation and Games!

The value of good models in System Engineering

Slow engineering – waste or valuable?

Bibliography