Guiding Principles

1. Guiding Principles A Walkthrough

2. 4 Parts • Name – a brief title that identifies the principle • Description – a paragraph that describes what the name covers; i.e. scope • Rationale – describes why this is a principle • Implications – these are organizational specific. If a principle is reused by an organization, the organization will need to determine what the implications are based on the context of the organization

3. Definitions • Common – known data types that can be standardized across an organization

4. References • IEC 61968-1

5. A common applications view of the AMI system • Description – common applications with known definitions that can be agreed upon; that they contain a common functionality that can be defined. • Rationale – interoperability depends on having a common set of applications and understanding what the boundaries of the functions are. Applications are defined as the embodiment of business functionality.

6. There is common data view of the AMI system • Description – common types, common data values and it needs to be consistent across all uses; data may be self-describing – the goal of this principle is that there is a common understanding of the data • Rationale – without common data it is more difficult to achieve application interoperability

7. Common organization • Description – logical organization of business applications; there is an understanding of what applications will interface. • Rationale – implies that there is an agreed set of categories of business functions; this produces the interface catalog. • Note: address centralized vs distributed

8. Extensibility • Description – this activity will prioritize functions with a focus on AMI functions, but does not preclude future extensions of the architecture; e.g. smart grid • Rationale – business requirements evolve over time; the location of business function may change • This group recognizes that smart grid represents a set of business functions and that AMI is a subset of that capability

9. Interoperability expectations • Description – (Consider IEEE or other reference for definition of interop); when custom integration is required it is not interoperable. Interoperability is manifested in ease of operation; we want more not less. It is not just interoperability within the organization, but across utility systems. • Rationale – interoperability is the fruit of good common practices. Systems that have greater interoperability have lower TCO.

10. Platform Agnostic • Description – a specific solution is not presumed; any implication of a specific technology or architecture is purely coincidental. There is an understanding that agnosticism is a counter weight to interoperability. • Rationale – there is an expectation of differentiation and innovation in the marketplace. The greater the dependence on a specific platform, the less flexibility architecturally there may be.

11. Align with existing standards • Description – reuse, harmonize, exploit, and profit from existing standards, e.g. ANSI C12.19, IEC 61968, DLMS/COSEM • Rationale – we don’t want to start from scratch, but leverage pre-existing work; borrow brains.

12. AMI work products are actionable and transferable • Description – any work (artifacts) that are created can be used by the audience for this work, e.g. vendors, regulators. There needs to be clear, explicit guidance for how to use the artifacts. There is an expectation that the work products are useful at lower levels of design. • Rationale – if its not consumable why bother; any work product must have business relevance.