This is a piccy of BABI…an application I built for a client a few years back (used with permission):
This image shows a schematic of an electricity substation. The main panel shows the current to-the-second state of the substation. The image is actually an SVG document that can be zoomed and panned and certain on-screen elements can be activated to actually control the sub’s activities. A given substation may have many panels like the one shown here.
Here’s how my CV describes the BABI project:
Development of a “world first” tool using C/J2EE and Scaleable Vector Graphics (SVG) to enable monitoring/control/visualisation of individual substations in [client]’s real-time SCADA system.”
It was an interesting project.
It is an open-standards based system using all the technologies that any web-oriented Java-head will have cut his/her teeth on. It offered XML-based configuration (and I built a tool chain to automatically generate about 80% of that from existing configuration files [some of which were PDP-11 binary dump files]), It used AJAX before the term was coined and it interfaced with fairly grungy C code (that, I am told, traces its ancestry back to assembly-language code built for an in-house operating system running on a PDP-7). On top of all that, it was written to live close to the hardware embedded in the bowels of a substation and also to provide a service to the corporate network to provide management with up-to-date oversight into the power network.
I don’t think that there is anywhere else in the world that has tried to do both command and control using these technologies and techniques.
I am proud of it.
While I was hacking it, I received a couple of visits from guys from the Canadian power systems specialists SNC-Lavalin who were blown away by the possibilities the project showed. SNC-Lavalin are trying to migrate away from their home-grown technologies and solutions to more open systems. I hope and believe that this project (in some small way) helped point them along the way…
Sadly, other than my own sense of self-satisfaction, I am not sure what else I can take away from the project: from the start I ran into all sorts of opposition from my colleagues (engineers and inveterate C-heads all): it was too slow, it took too much RAM (it ran under IBM’s J9 J2ME JVM on a Pentium II box with 128M of RAM), it used an externally-sourced framework and so was inherently ‘untrustworthy’, Java could never do anything ‘real’, it wasn’t thread-safe (whoops! a little bug there…in the JNI/C side, ironically [that wasn’t deliberate, honest!]), SVG was untried and doomed, ditto Javascript, ditto XML, one can’t trust a browser to support a ‘real’ application, etc., etc.
I’m pretty sure that [client] will do away with it as soon as they possibly can find the excuse to do so (the grapevine tells me that this is already happening). So much easier retreating into a well-tried and trusted comfort zone than trying to learn and understand what they actually have on their hands (a powerful and adaptable bit of infrastructure, if I do say so myself) and we all know that building a whole system from scratch is so much better and more satisfying than relying on open (source) standards like much of the rest of the world…
Note that this was technically a fairly successful project, was driven by management requirements, was demoed to and received management blessing (thanks, guys!) all through the development process, and so on.
Still, when push comes to shove, none of my colleagues want to maintain it and keep applying it…seems like none of them want to be ‘tainted’ by Java…
I must say that I found/find this visceral, ideologically-driven response vaguely depressing.
[This presentation resonated with me, when I first watched it.]
The aphorism that most readily comes to mind is: “You can take a horse to water, but you cannot make it drink.”
That is actually lesson 1.
There IS one other lesson I can take away:
During development, I would be thinking (as one does…sometimes) “here’s something cool that could be done in a later version” or “I’ll probably have to revisit this in 1.1, but this gets me up and running for now” and so on. I didn’t understand at the time that [client] can only really handle the idea of software as “mysterious black box” that is perfect on day 0 and will never be developed further.
[client] does do bugfixes on their code, and occassionally (rarely) adds a new bit of code, as circumstances demand. However, this does not mean that they manage the lifecycle of their systems: they are reactive, not proactive. Engineers fixing problems, not software people maximising, maintaining and developing their investment.
Embedded systems don’t get maintained; they get replaced.
Appearances (and IMHO needs) notwithstanding, I was building an embedded system…
Still…
If you live in Brisbane, your power is being controlled using this application.
As far as I know, no one has been electrocuted yet, so something must be right about it.
