By Wayne Morrow and George Strickland
Designing user-centered lighting control systems in an increasingly regulated world can be a real challenge. Many designers just give up and throw the problem over the wall to the engineers, resulting in a design that meets code but forgets the user. Fortunately, continuing advances in digital lighting control equipment and design tools are changing that paradigm. The use of new object-oriented design methods can untangle the design process, allowing architects to take back control while still providing exceptional energy performance and regulatory compliance.
Lighting control systems used to be simple. Lights had two possible behaviors and provided two user services: turn the lights on, turn them off - maybe add a time clock or photocell - but that was about it. Todays needs and expectations are different. The change has happened a little at a time over many years. Like the story of the frog staying in increasingly hot water until it's too late, design complexity has crept up on us.
Automatic off, occupancy sensors, daylight zoning, scene control, dimming, and a growing list of energy requirements and user demands have steadily been added to the pile.
Daylighting management systems have some of the most complex energy requirements. These systems take input from light level sensors, occupancy sensors, and solar angle tracking software to control the position of motorized blinds, window shades, and light shelves, optimizing the use of natural lighting and reducing consumption of electric lighting.
Recently, we saw a design for a single room that contained 12 on/off buttons, two dimmers, a key switch (to keep out the untrained), and finally a panic button to override everything to, well, on/off. Add to this the demands of fast-track scheduling, sequential design methods, and change-resistant hard-wired installations and it's easy to see why lighting control may seem to have become impossibly difficult.
The problem is that sequential, paper-based design methods and switch-based control technology really haven't changed much in the last 100 years. Designers are still trying to solve 21st century problems with 19th century equipment and design procedures. Clearly we need a new approach.
|Object-Oriented Design Process |
- Program Planning: Define why the building is being built.
- Use Case Development: In nontechnical terms, define how users and other "actors" are expected to interact with the system.
- Static Element Design: Define building envelope, electric lighting, façade features, and other static elements that affect lighting.
- Dynamic Element Design: Define dynamic elements such as automated lighting, shading, and natural ventilation and model their behavior.
- Secondary Design: Release for system integration, engineering, code compliance, and other design and engineering not specifically related to the architectural design.
Most designers would agree that lighting control has become too complex. However, complexity is manageable. Cell phones and computers are complex but these and many other technical marvels have become staples of our society. Complexity is managed by creating systems. When we think of these devices we think of a single thing: a "chunk." According to a 1956 paper published by psychologist George Miller, human beings can contemplate five to nine items, or chunks, at a time (Ross, pg. 68). A designer trying to incorporate multiple energy constraints, building objectives, and user needs all at the same time is likely to exceed this number and become overwhelmed. To be effective, designers need to limit and prioritize the design task.
Object-oriented Design (OOD) Steps
On the face of it, OOD is not all that different from conventional design. Buildings have always been built to meet objectives and serve user needs. However, increasing complexity requires a more structured process such as OOD to assure that those objectives are met and expected services provided.
Step 1. Program Planning: This is an obvious but essential step defining the project purpose, objectives, mission, goals, and expectations of the owners, users, and other stakeholders: the big picture.
Step 2. Use Case Development: Modern software design starts with use cases. These are nontechnical diagrams or statements that model a system as a black box in order to show the interaction with users, also called "actors." In the case of lighting design, actors can be humans, machines, institutions, regulators, utilities, and others. Use cases are the basis for the lighting user interface. They describe who the users are, their priorities, and how they will interact with the system. Architects are ideally positioned to define these interactions. Later on, engineers, managers, operators, regulators, and others may add additional use case requirements, but it is essential that the first cut is made by the architect and/or lighting designer, who most intimately understands the primary objective and needs of the system.
Form should follow function for physical interfaces, and users should be given convenient and nonintrusive methods for providing input. A study by the Lighting Research Center (Maniccia) found that office users preferred desktop over wall-mounted lighting adjustment by a factor of 6 to 1. The same study found that, given a choice, users do adjust their lights and shades, that their preferred light levels could not be predicted by age or task, and that preferences generally fell into a bell curve. Asked why they adjusted their lights, the No. 1 reason given was visual comfort to support a given task. This means that in order to be effective, use cases should take personal preference and individual interaction into account.
Use cases should be simple, nontechnical descriptions of how users will interact with the system and the services they expect to receive. For example, visualize a user walking into his private office. The automatic blinds are positioned to maximize natural light and minimize heat gain. The lights are gently ramped up and combine with the natural light to meet a preset level. After walking across the office and sitting down at his workstation, the user realizes the lights are brighter than he would like, so he pops up a control screen to lower them a bit. Later on, when he leaves for lunch, the lights gently lower to a standby setting, and after 10 minutes they turn off. This is only one possible scenario but it tells us a lot about the required system capabilities.
Today's digital designer has a wide range and variety of design options with few physical constraints. Digital control is inherently multistation and multifeatured. Buttons can be dimmers, on/off, or scene presets. Lights can fade up and down and have automatic on/off and interim warning stages. Points of control can be a wall station, LCD touch screen, personal workstation, web page, or personal wireless device. Use cases allow the designer to imagine a basic set of controls and then think through various scenarios to see if the controls do the job - ignoring energy codes, daylight zoning, and other factors unless they potentially affect the user interaction.
The outcome of use case development may be a set of control requirements or a written description of how the system needs to operate. Later on, the control designer will instantiate use case defined needs into actual commands, equipment, and functions, but at this stage they should remain general.
Step 3. Static Element Design:The first step in implementing the lighting design is to define the building envelope, electric lighting, façade features, and other static elements that affect lighting. Window placement and glazing, floor layout, static light shelves, building orientation, and fixture placement are all static elements that define the building space and lighting environment. Control is only required for the dynamic elements - those elements that need to change in response to environmental and human variables. However, these two elements - static and dynamic - are closely related.
Computer modeling techniques such as photometric and daylight calculations have made it possible to optimize the selection of static elements and determine the necessary range and operation of the dynamic variables. Daylighting design is an important example. Light comes from both artificial and natural sources, and energy and ergonomic factors can conflict. Clearer glass is better for occupants but worse for solar gain; maximizing daylight penetration may increase energy savings but also creates unwanted glare and reduces user comfort. Dynamic elements can fill the gap. An automated shading and lighting control strategy can be employed. Motorized shades can be lowered to intercept direct sun, and lights can be dimmed to maintain constant light levels (and significantly reduce energy use) when daylight is present.
Integrating multiple building systgems can be a complicated endeavor, but object-oriented design methods can help limit and prioritze the task.
Step 4. Dynamic Element Design: Object-oriented design sees a system as a group of interacting dynamic objects that have properties, behaviors, states, and values.
Control Objects: Object-oriented programming needs objects, and a lighting design has many. "An object is any useful item that has identity, structure, and behavior," (Chonoles, pg. 39). For architects, these are all of the user stations; light fixtures; motorized sun shades, venetian blinds, and light shelves; and other dynamic elements that are shown on the drawings. With CAD drawings, each object's properties can be defined with block attributes. Important attributes for each light fixture are fixture type, location (room number), power circuit connection, and zone membership(s). Entered in a structured format, this data can feed forward and become the basis for system configuration, zoning, and user control. Block attributes also simplify future design changes, with subsequent circuit assignments made by the engineer and zoning either assigned by the designer or dynamically assigned by an operating model.
Functional Model: If you can model it you can control it: A surprising statement but very much in line with modern control theory. Consider the traditional thermostat patented in 1883 by Warren S. Johnson. This is a mechanical device that uses closed-loop control logic. A sensor in each zone senses the temperature and modulates a heat source to maintain a temperature setpoint. Simple and effective for temperature control, but potentially problematic for lighting systems as complexity and building size increase. The alternative is open-loop logic, used by most industrial processes. Open-loop logic depends on a computer model to create feedback. Applied to daylighting, open-loop methods can potentially control an entire building with just a few reference sensors placed on the roof. The sensors provide input to the model and the model determines light level and shade position.
Fixture Block with Attributes
Above Illustration, Left: Fixture type (this can be any dynamic element: a light fixture, a motorized shade, a motorized light shelf, or other) and address as displayed on drawing.
Above Illustration, Right: Exploded block showing fixture attributes for fixture type (FIX), address (ADDR), room (RM), power panel (PNL), circuit (CIR), and up to five zone memberships (Z1-5). The architectural designer creates the block and fills in the fixture type, room number, and maybe zone assignments, while the address and circuit assignments are typically done later by engineers.
Static Objects Defined by Architecture
- Window placement, size, glazing, orientation
- Electric light fixtures
- Light shelves
- Location and orientation
- Zoning (static)
- User control stations
- Sensor placement (closed-loop systems)
Object Properties Defined by Engineers and Systems Integrator
- Power connection
- Control network connection
Dynamic Object Properties Defined by Control Model
- Zones (dynamic)
- Motorized sun shade position
- Motorized venetian blind angle
- Electric light level
- Motorized light shelving position
- Natural ventilation: motorized window vents and dampers
Input Variables Determined by Sensors, User Inputs, and System Variables
- Sky condition - cloudy or clear
- Outside light level
- Sun position
- Outside temperature - current and predicted
- Wind velocity - current and predicted
- Manual control requests
- Time of day
Step 5. Secondary Design: Once the architectural design and use cases have been completed the design can be released for further engineering design, including systems integration, code compliance, power distribution, and other design and engineering elements not specifically related to the architectural design.
Systems Integration: Digital lighting control is a building automation system (BAS). It has a similar architecture and network communications infrastructure that allow it to share data and control commands with other automation systems. Lighting control systems typically collect occupancy data and, after using it locally, pass it on to the HVAC and security systems for additional applications. In turn, the security, HVAC, and emergency power systems may need to initiate emergency lighting states and override normal operation. To the extent that these functions are part of the architectural design they should be defined as use cases. Otherwise, they can be left to engineers to define as background operations added during engineering and systems integration.
Code Compliance: Energy and other building codes can make significant demands on the control system. Unless these demands specifically affect users, they are best treated as background functions. Do users really care about or want to adjust daylight harvesting functions? In some cases, yes; in others, no. All automated systems, including sun shades, lighting, and natural ventilation, should have provisions for manual override that may include some scene preset responses. To the extent that users see value in controlling these functions they should be included in use cases. Otherwise, functions such as peak shaving, load shedding, daylighting, automatic off, on-at-50-percent, and other functions and requirements that provide no direct benefit to users should be treated as background functions invisible to users.
Like every other aspect of building design, the lighting control system should fit the function. A building requiring only basic on/off functions should be designed with a simple switch system. Digital systems have an inherently high initial system cost, but as control requirements increase, these costs are often more than offset by installation and design savings. Owners may also place high value on the inherent flexibility, adaptability, central management, and other capabilities of digital systems they have come to expect from other BAS systems. With increasing system complexity, rising energy costs, and required features like on-demand peak shaving and centralized commissioning, digital systems may well be the only practical answer.
Wayne Morrow is a senior application engineer at Starfield Controls. George Strickland is a commercial specifications manager at Somfy Canada.
Chonoles, Michael Jesse; James A. Schardt, UML 2 for Dummies, Wiley Publishing, 2003.
Somfy Nordic AB, Sun Shading: Effects on Energy, Working Environment, Design.
Ross, Philip E., "The Expert Mind," Scientific American, August 2006, pp. 64-71.
Maniccia, Dorene; Burr Rutledge, Mark S. Rea, Nadarajah Narendran, 1998. A Field Study of Lighting Controls. Rensselaer Polytechnic Institute, Lighting Research Center, Troy, NY.
Additional publications on lighting control, occupant behavior, and fixture blocks.
Additional information about management of dynamic façades.