Use cases are scenario descriptions of system behavior that define requirements under various conditions of operation. They can be described in summary form as diagrams and are expressed in complete form as narratives. They were developed for use in the specification of software systems, but apply to systems of any type. They are useful to define the scope of the behaviors involved in system operations and the players (actors) involved in the accomplishment of the involved interactions. Actors are defined by the roles they play, and individual players may be defined multiple times in the same set of use cases under different names based on different behaviors demonstrating different responsibilities associated with distinct roles. Actors (roles) may be actualized by one or more players in the system who perform similar functions.
The 148Avenida Use Case View is a subset of the scenario set for EATSv5. The images below presents a cascade of three Use Case Diagrams resolving focus on the technical challenges related to goal accomplishment presented by home automation. These challenges are not specific to openHAB, but they are inclusive of the challenges presented by the 148Avenida project as a cyber-physical system (CPS). The challenges are also not specific to 148Avenida as a site, or home automation as a function, rather they are representative of general challenges presented by most, non-trivial CPS projects. Although the details provided will be specific to 148Avenida, they apply generally to home automation and conceptually to other systems when viewed in their context as mixed-mode, human plus cyber-mechanics, CPS exercises.
The principal elements of a use case diagram are Actors and Uses Cases defining scenarios of concern within the context of the scope of the system of concern. The scope needs to include the whole of the context of consequence for understanding the behavior of the system relative to the concerns to be addressed.
There is no correct place to draw the boundary box around the system, and it can be drawn in different places depending on the concerns. In the case of a use case diagram it is less a question of drawing the box than a question of the definition of how many actors, which actors, how many use cases, and which use cases to include; and which actors go inside or outside the box.
Actors define the parties or things performing roles that drive the behavioral activity of the system. Almost all use case diagrams include people as actors, but actors are not synonymous with people. People as actors tend to be the motivational stakeholders whose intentions to cause behavior are the driving force behind the processing requirements of the system.
To understand home automation as opposed to device automation the proper place to start is with a contextual understanding of home. Failure to understand that distinction immediately leads to a failure to understand the boundaries of the system, which leads to a false definition of what is the system. The first two diagrams presented here are intended to illuminate that distinction to help understand why certain things do and don’t work, and the challenges with achieving general objectives.
The diagram to the left is a use case for home management with or without home automation. There are two human actors in the system defining the roles played by the occupants of the home. All occupants are users of the home and its facilities. Two use cases are defined, the difference between which is related to the role distinction drawn between the users. One use case defines the management and maintenance of the home, performed by occupants in an administrative role, and the other use case involves day-to-day utilization of the home performed by all occupants in their general use of the home. The general use of the home is the primary use case and the behavior of the home regarding the needs of its occupants is the behavior attempting to be regulated as a function of the design of the system. The remaining four elements in the diagram define secondary actors which also have roles in defining and regulating the behavior of the home. The behaviors, which are not defined or shown in the diagram, but would be defined in a formal use case narrative, are conditions or states changes or effects. The home becoming comfortable as a function of heating being activated is behavior. The home providing illumination for activities is behavior. Toaster and coffee-maker function to cook and heat food is behavior. The actors which drive these functions in a modern home are mechanical systems, some of which are driven by time-of-day activation, the devices they activate, and independent devices, such as switches, which are activated to cause the behavioral effects that are desired by the occupant users. The objective behavior of device automation is the behavioral effect created by the operation of one or more subsystems within the home, such as the furnace, which has no effect on lighting or cooking food. The objective behavior of home automation is the sum of all of these devices for the benefit of the sum of all of the occupants.
Full home automation would require that all mechanical control systems in the home be automated, which is unrealistic short of NCC-17011The first challenge would be personal finances; but beyond budgetary considerations some elements would require innovations that are economically and technically infeasible at this time for any but the world’s wealthiest maker hobbyist.. Rather than all, realism dictates we limit automated control as a realizable objective to a coordinated subset of the mechanical secondary actors used to manage home behavior. Viable home automation in 2020, and for some period of time, involves increasing system complexity by adding additional secondary actors into the system as shown in the expanded use case diagram on the right. Hypothetically the increase in complexity is offset (paid for) by increased benefit accrued to the occupants. This increase in complexity is a major impediment in acceptance of the technology. Successful home automation architectures need to acknowledge the impediment and be designed as good regulators to get past being labeled as device, rather than home, automation. Replacing a manual light switch with an automated light switch is not a one-for-one exchange in variability when a phone or additional control panel is introduced as a required item to control the switch in order to control the lighting. It’s an increase in complexity. Adding color as a choice to be made when turning on a light does not simplify the process, it makes it more complex. Home automation needs to reduce complexity at the same time as increasing functional utility to become a viable component of home architecture.
Viable Home Automation Use Case
Polymorphic encapsulation is typically seen expressed in class hierarchy diagrams such as the Actor hierarchy shown at left. This is an object-oriented layering of system specifications where more detailed (concrete) Actor types, depicted lower in the diagram, are shown to be derived from more general (abstract) types (classes) depicted higher in the diagram. (The position is not technically what defines the order of derivation. Rather it is the symbol set where the arrow head points to the more general class.) The same general to detail encapsulation can also be shown in use case diagrams, and is used for the user-admin relationship already shown.
The Home Management Contextual Use Case can be viewed as a high level view of the same system presented in the Home Automation Contextual Use Case when Automated Systems is seen to be a special case instance of Mechanical Systems and the Automated Device a special case of Mechanical Device. In that manner the second use case can be viewed as a detailing of the first. The difference is that in the second diagram we have separated out automated (mechanical) systems from regular mechanical systems as systems having special distinctions of interest. The conceptual encapsulation is shown in the class diagram above, but is not specifically delineated in the use case diagrams to avoid detail which is orthogonal to the point of interest in the use case diagrams. In the Home Automation Contextual Use Case Mechanical Systems becomes Device Controller in the class diagram. Device Controller in the Abstract System is the regulator mechanism actualized as Thermostat in the Physical System. In the same manner Mechanical Device becomes Controlled Device actualized as Furnace. The link between Thermostat and Furnace in the Physical System is a specification of collaboration, where Thermostat interacts with Furnace, not a sub-type arrangement. In the same context Automated Systems becomes Automated Controller (a specialized extension of Device Controller) as the regulator mechanism actualized as Home Automation System, and Automated Device in the use case becomes Automated Device (a specialized extension of Controlled Device) in the class diagram actualized as Garage Door. The link between Home Automation System and Garage Door in the Physical System is a specification of collaboration indicating that minimally the Home Automation System includes Garage Door operating functions.
The Good Regulator Theorem of Conant and Ashby state that the variability within the regulator needs to equal or exceed the variability of significance within the system being regulated. The variability in home automation includes all of the factors of consequence to be managed, and all of the mechanisms used to influence those factors. Furthermore, feedback must exist between the system being regulated and the regulator on the issues of concern to the regulation policy. In the Home Automation Contextual Use Case there is no interaction between the three device types or the regulators for the two types of controlled devices. In some cases this might be inconsequential, in other cases it isn’t.
If the Independent Device in the use case is a living room light, the mechanically controlled device is the furnace, and the automation controlled device is the garage door; there may not be conflict, and no obvious benefit from coordination. If the light is a garage light there begins to be a desire for possible coordination between the light and the garage door. If all three systems relate to the living room lighting (lights controlled via a light switch, lights on a simple timer, and colored lighting controlled by a home automation system (e.g., Hue), the desire for coordination becomes greater. Lack of such coordination in the home automation system leave the regulator responsibility up to the home occupant to coordinate turning lights on and off, and coordinating between lighting arrangements to effect mood. The more such systems are brought together in the same context, the same home, to impact the same space (e.g., living room temperature, lighting, music, etc.) using uncoordinated or incompatible systems, the greater the combination creates a burden rather than a benefit to the home occupant. Conflicts can also arise with systems that are compatible but where overlapping roles create issues of responsibility. One example is “Hey Google” when spoken in proximity of both a phone and a Google Nest each of which independently try to become the respondent.
The 148Avenida project assumes the Home Automation Contextual Use Case with:
- Some aspects of home operation functioning as independent devices entirely under the operational management of the home occupants for the foreseeable future. These include simple lights, plugs and appliances that are controlled using pre-automation, direct control, mechanical switches and mechanisms.
- Some aspects of home operation functioning under the control of mechanized systems specific to dedicated tasks. These may include thermostat controlled heating and air conditioning, solar energy systems, alarm systems, etc..
- Some of these systems may be capable of information or control sharing, in which case interface with the home automation system is a desired feature.
- Some aspects of home operation functioning as automation managed appliances. This is the area where consolidation under a master controller becomes the objective rather than multiple, independently managed automation systems.
The use case diagram below provides a lower level of detail for use in the specification of a viable (good regulator) home automation architecture which attempts to take these factors into account. The totality of home operation is still the responsibility of the home occupant as the regulator. (This is not NCC-1701.) Otherwise independent mechanized systems which are capable of interface are included in the design. Mechanisms managed by automated home control systems are capable of integrated management, but that capability is limited by the selection of the automated systems to products based on APIs that provide for inter-connectivity. Use of systems which do not provide for such inter-connectivity create additional complexity which becomes the responsibility of the home occupant for regulation.
Viable Home Automation Architecture Diagram
The responsibilities and role of the administrator and administration use case are unchanged. The distinction however is that the administrative use case helps with the reduction of variability for the administrator by coordinating administration of the encapsulated sub-systems (Federated Controllers) as a responsibility of a master regulator (Automation Controller)2The Automation Controller must include a model of the Federated Controller administrative function within its own administrative functions..
The operation use case and the interactions of the general user have been detailed into the three new use cases shown here. In addition the mechanisms used for interaction with the system have been detailed to show distinctions between direct manipulation of controlled devices (e.g., turning controlled lights on and off directly via light switches), and interactions through automation control devices that may be local or remote from the home and the controlled systems. To reduce complexity these distinctions in control need to options of choice made by the user, not requirements of differentiation where different methods are required based on the task to be performed or the device to be controlled.
(Use case narratives)
- Home Utilities
- Home Automation Schedules
- Sensor Schedule
- Home Environmental Management
- Home Lighting
- Home Security
- Home Power Generation
- Home Power Storage
- Home Power Utilization
- Home Weather Station
- Home Astronomy Station
- Home Automation Schedules
- 148Avenida Use Case View
- 148Avenida Logical View
- 148Avenida Process View
- 148Avenida Physical View
- 148Avenida Configuration
- Security Configuration
- 148Avenida Developer View
- v2.5.5 Runtime Issues
- Development Setup Issues
- Eclipse SmartHome Framework
- Coding Guidelines
- Eclipse Community
- Framework Utilities
- Package Dependencies
- REST API
- Testing Eclipse SmartHome
- Textual Configuration