A systems architecture is the conceptual model that defines the structure, behavior, and key operating parameters of an integrated system. An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structure of the system which comprises system components, the externally visible properties of those components, the relationships (e.g. the behavior) between them, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. The language for architecture description is called the architecture description language (ADL).
Scope and Objective
The objective of this architecture design is to satisfy the need to have the following features.
- Overarching architecture document that clarifies interaction between the various FREEDM system components.
- Easy to use tools and schemas for capturing relevant architecture information.
- Link various cyberphysical aspects of a FREEDM System such as physical components, control loops, software components, communications, interfaces.
- Architecture documentation should support cross-team development, system verification, failure mode analysis, etc.
The architecture should capture,
- Physical devices in FREEDM System
- Interaction between Control Loops
- How various applications are enabled
- Time frames for control and optimization algorithms
- Communications and security structure
- How use cases are supported
Approach
FREEDM Architecture and Working Group (FAWG) leverages extensive investment in systems-level use-case analysis and systems engineering training done in earlier years of the center that resulted in two artifacts; a use case document and system control architecture. What was lacking in earlier years is an overall system architecture that can represent the FREEDM system including its solid state components, low-level power system components, control functions, device architecture, management architecture, and enterprise architecture. There are a number of industry models and practices that represent software architecture (UML), hardware architecture (VHDL), and system component interactions (one line diagrams) to name a few, but there is not an overarching model that can represent the range of FREEDM components. SysML approaches this goal, but has a heavyweight syntax with a learning curve and a modeling aspect that is foreign to the skill sets of many of the investigators in the center. What is needed is a model that can both syntactically and semantically represent the diversity of components that make up a FREEDM system.
The FAWG group developed an architectural representation that is simple and encompasses the following five primary features: the functionality of a component, what its timing constraints are, where it executes, what are its governing invariants, what are the exceptions that occur when the governing invariants are not met, and what are the semantic interrelationships among the components. The group borrowed from the Software Engineering UML model, simplifying its syntax to blur the distinction among hardware, software, and network components. A component schema represents the first four features. The semantic relationship is a free-form style that captures interactions of control signals, network messages, and object inheritance.
Accomplishments
The project, in its first 5 months of Year 7, has documented 100 component objects and 50 classes of objects present in the architecture of FREEDM. Using this architecture, several subthrusts have used it as a “Rosetta Stone” to understand their subcomponent interactions. The architecture has also uncovered conflicting designs, particularly in the Energy Management actions of DGI.
Next Steps
The requirements elicitation process continues as the Center integrates the FREEDM system. The Center will be well positioned to develop and implement governing invariants over FREEDM. The system level management (DGI) in FREEDM has been developed from the use case requirements elicited by the systems engineering process. The FAWG architecture has proven to be helpful in furthering the systems 35 engineering culture among the FREEDM stakeholders in algorithms, software and hardware. Empirical evidence suggests that the syntax and semantics of the FAWG are readily understandable by a diverse set of groups. The ensuring months will also collect survey data on the use of the FAWG. The FAWG can be extended beyond the FREEDM system, itself, into the enterprise architecture of the utility. This extension will be able to represent FREEDM’s value proposition much in the way the European SGAM model has addressed enterprise-level requirements of the electric smart grid.