Guiding Principles A Walkthrough

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

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

References IEC

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.

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

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

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

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.

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.

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.

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.