I used to work for an electronic controls company, and I recently started thinking big picture about how the software was laid out. When I was knee deep in the details, I had a mind full of notions about what was going on. Fundamentally, I think this is my takeaway.
Object Oriented design makes a good deal of sense when you really are modeling the behavior of physical objects. Many of the basic principles were there, like a powered down smalltalk system. The design tools were essentially object databases which were compiled into microcode for the appropriate hardware. On the large scale (full building to campus scale) systems, the compartmentalization was fairly rational. So to design a building, you divide it into floors or other reasonable real world divisions (maybe an exterior area for all outdoor controls), then divide those into rooms or suites of rooms. Within a room, you add controls and controllable objects (lights in my case, but it could easily have been other items). Some systems provided default behavior for free, which could be customized afterward (a light switch in a room automatically turns lights on and off until you program it otherwise). Some systems did not do this at all, but had a much richer set of allowable programming. For example, the residential system used a separate hardware and software system targeted to third party integrators, while the commercial system was essentially an internal tool. Building the database essentially consisted in reading the construction diagrams and adding each unit and its function into the database.
This model (Object Oriented drag and drop database tool) had its limitations. For example, a common residential control had a large on/off button, which supported a double-tap as a special command, and a raise/lower rocker off to one side. The raise lower were likely to be left alone, since there are few sensible overrides, but double-tap could be adjusted to do just about anything. Just about... It seems one downfall of the OO ideology is that some objects support a different set of methods than others. So while a multibutton keypad could handle fairly complex conditional behavior, this was not allowed in the single button toggle switch, even from double tap. This behavior was not extensible at runtime. Many of the buttons allowed chaining other buttons (sending a keypress event) to allow some impressive logic. Some types of controls did not support this 'dolikepress control key' method. Sadly, the workaround was that it did allow sending rs232 commands from the onboard serial port. I once had to install a few loopback wires to tie com1 to com2 so that the second class control could implement first class behavior (using the rs232 serial command to send a press event to a key which could handle the command I needed). This of course was done with cryptic string literals. Try showing someone how that's done and expecting them to be able to replicate it.
One other thing I saw while I was there was the evolution of the granularity of control. The company moved from a circuit based centralized concept to a distributed item level design (with a mix and some tension between cabling controls to the nearest connected device or back to a central hub). This introduced a new level of complexity (in that rather than addressing a unit as 12, attaching it to wire 3 running back to the hub, it now was indirectly accessed as the control attached to device 20 on link 4, etc) but freed up the electrical topology and cut costs of cabling for installers. I see how on the business end this made a great deal of sense. There also was a general tendency to move away from addressing (via dip switches, in software menus etc) to serial number addressing. Unfortunately, the database design ideas still required a set address/location pair for the design, and some time was spent on each installation associating control serial numbers with database id's. The goal was to make replacement simple, with only removal and replacement sufficient to allow the hub to infer the new devices behavior, but this had problems if there was more than one failed item on a cable (since there could be no unambiguous solution, the system did nothing) or multiple replacements at a time. This led to some interesting hangups where power was removed from a portion of a floor (not uncommon in construction). In the end, some manual intervention in the software was required to overcome this hurdle (in the several years since I left, I imagine this has been corrected, since manpower costs money).
On the whole, although I found the drag and drop available actions easy to explain, but it failed to abstract away the details, since the desire to maintain programmability and flexibility (yes, we can do that) outweighed the need to provide an intuitive and flexible system for end users. Really, the end user only wants the lights to turn on when he hits a button, and the support/maintenance team that inherits a beast of a control system is used to dealing with 10 different hardware control platforms.
I think the BACnet integrators are making a good deal of headway into alleviating this pain for the building managers, though not coming from a ladder diagram world, I found programming with Vizio a little queer. But having one software control system to view AC, alarms, security, lights, and handle all timed control events is a big win for the maintenance staff.
No comments:
Post a Comment