INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
System Interfaces For Distribution Management –
Part 3: Interface Standard for Customer Support
FOREWORD
1) The IEC (International Electrotechnical Commission) is a worldwide organization for standa rdization comprising
all national electrotechnical committees (IEC National Committees). The object of the IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, the IEC publishes International Standards. Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non-governmental organizations liasing with the IEC also participate in this preparation. The IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between th e two organizations.
2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation from all interested National Committees.
3) The documents produced have the form of recommendations for international use and are published in the form
of standards, technical reports or guides and they are accepted by the National Committees in that sense.
4) In order to promote international unification, IEC National Committees undertake to apply IEC International
Standards transparently to the maximum extent possible in their national and regional standards. Any divergence between the IEC Standard and the corresponding national or regional standard shall be clearly indicated in the latter.
5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with one of its standards.
6) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject
of patent rights. The IEC shall not be held responsible for identifying any or all such patent rights. International Standard IEC 61968 has been prepared by Working Group 14, of IEC technical committee 57: Power System Control And Associated Communications.
The text of this standard is based on the following documents:
Full information on the voting for the approval of this standard can be found in the report on voting indicated in the above table.
CONTENTS
Page
1 Scope (6)
1.1 Scope of full standard (6)
1.2 Scope of this Part (6)
2 Normative references (6)
3 Reference and Information Models (7)
3.1 Introduction (7)
3.2 Interface Reference Model (7)
3.3 Customer Support Functions and Components (7)
3.4 Message Types (8)
3.4.1 Message Type Nouns (9)
3.5 Static Information Model (11)
4 Customer Support Message Types (12)
4.1 Message Usage (12)
4.2 Message formats (12)
4.3 Query-by-example (12)
4.4 Common message type fields (12)
4.5 Compliance (13)
5 Customer Support Documents (14)
5.1 Trouble Ticket (14)
5.1.1 Message format (14)
5.2 Outage Record (15)
5.2.1 Message format (15)
5.3 Planned Outage Notification (16)
5.3.1 Message format (16)
5.4 Call Back (17)
5.4.1 Message format (17)
5.5 Outage Follow-Up Event (17)
5.5.1 Message format (18)
5.6 Regulatory Standard Violation Warning (18)
5.6.1 Message format (18)
5.7 Customer Outage History Message Types: (19)
5.7.1 Message format (19)
5.8 Customer Connection (19)
5.8.1 Message Format (19)
5.9 ServiceExtension Request (20)
5.9.1 Message Format (20)
5.10 Extesion Project Record (20)
5.10.1 Message Format (20)
5.11 Customer Billing (21)
5.11.1 Message Format (21)
5.12 Construction Billing (21)
5.12.1 Message Format (21)
5.13 CustomerServiceAgreement (21)
5.13.1 Message Format (22)
Informative Annex (22)
ANNEX A: Relevant Packages of the Common Information Model (IEC 61968-11) (23)
Documentation - Overview (23)
Documentation - Network Data Set (24)
Documentation – Operational (25)
Documentation - Outage Mangement (26)
ANNEX B: Informative: Description of Message Type Verbs (28)
Tables
Table 1: Document Overview For IEC 61968 - Part 3 (5)
IEC 61968
System Interfaces For Distribution Management –
Part 8: Interface Standard for Customer Inquiry
Introduction
The IEC 61968 series of standards is intended to facilitate inter-application integration as opposed to intra-application integration. Intra-application integration is aimed at programs in the same application system, usually communicating with each other using middleware that is embedded in their underlying runtime environment, and tends to be optimised for close, real-time, synchronous connections and interactive request/reply or conversation communication models. IEC 61968, by contrast, is intended to support the inter-application integration of a utility enterprise that needs to connect disparate applications that are already built or new (legacy or purchased applications), each supported by dissimilar runtime environments. Therefore, these interface standards are relevant to loosely coupled applications with more heterogeneity in languages, operating systems, protocols and management tools. This series of standards is intended to support applications that need to exchange data every few seconds, minutes, or hours rather than waiting for a nightly batch run. This series of standards, which are intended to be implemented with middleware services that exchange messages among applications, will complement, not replace utility data warehouses, data base gateways, and operational stores.
As used in IEC 61968, a Distribution Management System (DMS) consists of various distributed application components for the utility to manage electrical distribution networks. These capabilities include monitoring and control of equipment for power delivery, management processes to ensure system reliability, voltage management, demand-side management, outage management, work management, automated mapping and facilities management. Standard interfaces are defined for each class of applications identified in the Interface Reference Model (IRM), which is described in Part 1: Interface Architecture and General Requirements
This Part contains the following clauses:
Table 1: Document Overview For IEC 61968 - Part 3
1 Scope
1.1 Scope of full standard
The IEC 61968 standard, taken as a whole, defines interfaces for the major elements of an interface architecture for Distribution Management Systems (DMS). Part 1:Interface Architecture and General Requirements, identifies and establishes requirements for standard interfaces based on an Interface Reference Model (IRM). Parts 3-10 of this standard define interfaces relevant to each of the major business functions described by the Interface Reference Model.
As used in IEC 61968, a DMS consists of various distributed application components for the utility to manage electrical distribution networks. These capabilities include monitoring and control of equipment for power delivery, management processes to ensure sys tem reliability, voltage management, demand-side management, outage management, work management, automated mapping and facilities management.
This set of standards is limited to the definition of interfaces and is implementation independent. It provides for interoperability among different computer systems, platforms, and languages. Methods and technologies used to implement functionality conforming to these interfaces are considered outside of the scope of these standards; only the interface itself is specified in these standards.
1.2 Scope of this Part
This document is Part 3 of the IEC 61968 standard and specifies the information content of a set of message types that can be used to support many of the business functions related to Customer Support. Typical uses of the message types defined in Part 3 include data acquisition by external systems, fault isolation, fault restoration, trouble management, maintaining plant, and commissioning plant.
2 Normative references
The following normative documents contain provisions, which through reference in this text, constitute provisions of this International Standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements based on this International Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest editions of the normative documents referred to apply. Members of IEC and ISO maintain registers of currently valid International Standards.
IEC 61698-3 Customer Support.
3 Reference and Information Models
3.1 Introduction
The message types defined in this document are based on a logical partitioning of the DMS business functions and components called the IEC 61968 Interface Reference Model.
The contents of the message types are based on a static information model to ensure consistency of field names and data types. Each message type is defined as a set of fields copied from Common Information Model (CIM) classes. The message types defined in this standard are intended to satisfy a majority of typical applications. In some project implementations, it may be desirable to modify the set of fields using a methodology such as that described in Part 1.
3.2 Interface Reference Model
It is not the intention of this standard to define the applications and systems that vendors should produce. It is expected that a concrete (physical) application will provide the functionality of one or more abstract (logical) components as listed in this standard. These abstract components are grouped by the business functions of the Interface Reference Model.
In this standard, the term abstract component is used to refer to that portion of a software system that supports one or more of the interfaces defined in Parts 3 to 10. It does not necessarily mean that compliant software is delivered as separate modules.
Part 1 of this standard describes infrastructure services common to all abstract components whilst Parts 3-10 define the details of the information exchanged for specific types of abstract component.
IEC 61968 defines that:
1. An inter-application infrastructure is compliant if it supplies services defined in Part 1 to
support at least two applications with interfaces compliant to sections of Parts 3 to 10.
2. An application interface is compliant if it supports the interface standards defined in Parts
3 to 10 for the relevant abstract components defined in the Interface Reference Model.
3. An application is only required to support interface standards of the applicable
components listed under Abstract Components. It is not required to support interfaces required by other Abstract Components of the same Business Sub-Function or within the same Business Function. While this standard primarily defines information exchanged among components in different business functions, it will occasionally also define information exchanged among components within a single Business Function when a strong market need for this capability has been realised.
3.3 Customer Support Functions and Components
It should be noted that the message types defined in this document: IEC 61968 Part 8: Interface Standard for Customer Support, may be sent or received by any type of component within a DMS system.
The following table shows these functions and typical abstract components that are expected to be producers of information for these message types. Typical consumers of the information include, but are not restricted to, the other components as listed in IEC 61968 Part 1 for example, Geographic Information Systems, Energy Management Systems, Customer Information Systems.
3.4 Message Types
The following use cases are used to identify message types for the Part3.
?Use Case UC13: Network Extension Planning
?Use Case 47: Fault Isolation, Repair and Restoration of Supply
?Use Case 02: Maintaining Plant
The message types defined in this standard are described using the following terms.
Message Type Name
Each message type has a name consisting of a Verb and a Noun
Message Type Verb
The Verb describes the purpose of the message. (See informative annex B for the description of the verbs used)
Message Type Noun
The Noun describes the type of data in the message body. Each noun corresponds to a class name in the static information model. For most message types, the Nouns are a type of Document.
Message Body
The body of each message type is based on the attributes (fields) of the classes described by the Nouns.
PowerSystemResource
This is an entity that describes a logical part of the utility business. P owerSystemResources are types of conducting equipment e.g. cable, transformers, switches etc. (See IEC61970 Part 301)
https://www.doczj.com/doc/2b6672365.html,
This is a human defined and readable alphanumeric string that identifies an entity with a specific scope e.g. within a particular substation.
IEC 61970 Part 301 does not define a way of identifying equipment with a single attribute. It is however usual for utilities to use unique alphanumeric codes to identify their substations and the equipment in each substation. In some implementations, these codes may have to be prefixed with additional characters to guarantee uniqueness across organisation boundaries.
In this standard, the term “PowerSystemResource.ID” means one of these alphanumeric codes. This is an alphanumeric string that identifies entities like PowerSystemResource and ConnectivityNode such that non-hierarchical relationships may be described within a message. IDs may be allocated by a software component or by a person.
Document.AliasName
It uniquely identifies a type of document
3.4.1 Message Type Nouns
The following set of nouns can be used within message types. Each noun corresponds to a class name in the static information model.
Nouns that are of type ‘Document’ are groupings of other objects and are used to form message type names.
Nouns that are of type ‘Part’ refers to objects that only exist as part of a larger document.
3.5 Static Information Model
The information model relevant to Customer Support consists of classes as described by the Nouns listed in Clause 3.4.1 together with the related classes that provide attributes for each message. All message types are based on a common model of a document (See Figure 3). An organisation may be a company or a division within a company.
4 Customer Support Message Types
Customer Support message types deals with documents associated with Trouble Call Management and Customer services.
4.1 Message Usage
This standard defines a set of message types for which an application can subscribe to. When a producer publishes such message types the subscribers receive the message. An information consumer component can also send a Get message type, to which an information producer component will respond with a Show message type.
4.2 Message formats
In general message types have been defined with fields that may hold different representations of the same data. It is expected that producer applications will set some fields with default null values.
In the message format descriptions, terms like Document.* mean all attributes of class Document from the static information model. Multiple copies of sets of attributes are indicated by the term [0..*].
4.3 Query-by-example
Some messages with verbs such as Get, Subscribe, Unsubscribe, can contain data used to select the data of interest. In some cases, the message body would simply be a set of explicit document reference numbers. In other cases the message body fields would contain expressions which allow a query to be constructed. If there are no message body fields, then this shall be interpreted to mean all documents of the relevant type.
Expressions will match ANSI standard SQL including
=,<,>,<=,>=,<>
LIKE
IN [
4.4 Common message type fields
The following fields shall be part of all message types defined in this standard.
Document.documentType
Document.AliasName
Document.revisionNumber
Document.documentStatus
Document.title
https://www.doczj.com/doc/2b6672365.html,ments
Document.createdBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.createdDateTime
Document.modifiedBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.modifiedDateTime
4.5 Compliance
This standard defines the logical names of message types and fields within message types. Compliance can be assessed separately for each message type. However it is expected that vendors will offer compliance for all messages defined in IEC 61968 Part 3.
A software component is deemed to be compliant to any specific message type if
1. The component can produce an XML message for a message type including all the fields
with names and data types as defined in this standard. Data may be set to a default value if it is not available within a component.
2. The component can read XML message produce for a message type defined in this
standard and correctly interpret the fields in the message.
5 Customer Support Documents
Customer support message types uses the following documents
?Trouble Ticket
?Outage Record
?Planned Outage Notification
?Outage Follow-up
?Customer Call Back
?Regulatory Standard Violation Warning
?Customer Outage History
?New Service Request
?Customer Billing
?Construction Billing
?Customer Connection
?Service Level Agreement
The subscription for any of these message types identifies the document type.
5.1 Trouble Ticket
When outage is not due to a Scada Trip, Electric Utilities depend on the calls from the customers to identify the location of the fault. The Trouble Ticket contains the information of a customer call.
5.1.1 Message format
CreatedTroubleTicket or ShowTroubleTicket message type has the following message format. Document.documentType
Document.AliasName
Document.revisionNumber
Document.documentStatus
Document.title
https://www.doczj.com/doc/2b6672365.html,ments
Document.createdBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.createdDateTime
Document.modifiedBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.modifiedDateTime
TroubleTicket.ErpAddress
TroubleTicket.ErpContact
TroubleTicket.EmergencyService
TroubleTicket.Operator Name
TroubleTicket.CallDateTime
TroubleTicket.StartDateOfProblem
TroubleTicket.ProblemInformation
TroubleTicket.ádvice
TroubleTicket.AccessDetails
TroubleTicket.CallBackRequired
TroubleTicket.ETACallBack
TroubleTicket.ETRCallBack
TroubleTicket.RestoreCallBack
TroubleTicket.CallBackContactDetails
5.2 Outage Record
An OutageRecord document describes details of an outage in part of the distribution network. Outage records indicate the affected power system resources and thus the customer Affected
An OutageRecord is typically produced as part of a planned activity (e.g. work order for maintenance) or following a breaker trip detected by SCADA or within a Trouble Call System by grouping calls from customers.
A Fault outage is created automatically following a SCADA trip. Any subsequent trouble call associated with the Outage is automatically grouped to the outage. A fault in the transformer breaker may result in supply loss for the downstream customers of all the Feeder Circuit Breaker fed by the transformer breaker.
When an outage is created solely based on trouble calls, an Incident is created on a ConductingElement based on the location of the first call. Subsequent associated calls are grouped progressively to the Incident. Position of the incident is dictated by the likely position of the fault. The operator turns the incident into an outage after the fault has been confirmed. An OutageRecord has an associated OutageStep for each supply point, e.g. distribution transformer or metered switch that is affected by the outage..
An OutageRecord has associated Remarks or Follow-up to list chronologically all the actions/events occurred during the restoration of the outage. This helps to monitor the progress of the outage and provides updates to customer enquiry
An OutageRecord has associated Crew identifying all the field cr ews and their current statuses during the restoration of the outage.
There may also be AdditionalWork associated with an outage. When this is the case the outage may not be allowed to close to history until the additional work has been completed even though the supply to all affected customers has been restored
Some of the fields e.g. OutageStep.fatality, OutageRemarks, AdditionalWork may be specific to particular utilities and systems. It should be noted that the https://www.doczj.com/doc/2b6672365.html,ments field is available for general-purpose text that can characterise the outage
Note: The Outage record message has been dealt with in part 3. It is included here for completeness of trouble call management.
5.2.1 Message format
CreatedOutageRecord, ChangedOutageRecord and ShowOutageRecord message types have the same message formats as shown below.
Document.documentType
Document.AliasName
Document.revisionNumber
Document.documentStatus
Document.title
https://www.doczj.com/doc/2b6672365.html,ments (free text comments)
Document.createdBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.createdDateTime
Document.modifiedBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.modifiedDateTime
OutageRecord.StartDateTime (Time of first call or device trip) OutageRecord.NumberOfCustomersNowOffSupply
OutageRecord.FirstDespatchTime
OutageRecord.EstimatedTimeOfRestoration
https://www.doczj.com/doc/2b6672365.html,pletedTime
OutageRecord.reason (utility specific concise text description) OutageRecord.suspect.ConductingEquipment.ID
OutageRecord.[0..1].SwitchingSchedule.AliasName
OutageRecord.[0..*].TroubleCallL.AliasName
OutageRecord. [0..*].Remarks.* (Outage Progress Log)
OutageRecord. [0..*].Crew.*
OutageRecord. [0..*].AdditionalWork.* (Description of work)
[0..*]
OutageStep.equipment.PowerSystemResource.ID
OutageStep.offDateTime
OutageStep.onDateTime (may be estimated restoration time)
OutageStep.jobPriority
OutageStep.numberTotalCustomers (connected to the PowerSystemresource) OutageStep.numberSpecialCustomers (e.g. high reliability required)
OutageStep.numberCriticalCustomers (e.g. with dialysis machine)
OutageStep.fatality (reported by caller or engineer Y/N/Null)
OutageStep.injury (reported by caller or engineer Y/N/Null)
OutageStep.shocks (reported by caller or engineer Y/N/Null)
OutageStep.damage (reported by caller or engineer Y/N/Null)
OutageStep.numberCallers (number of customers phoning in) GetOutageRecord, CanceledOutageRecord, ClosedOutageRecord and DeletedOutageRecord identify only the documents
5.3 Planned Outage Notification
When an outage is planned due to a new service or equipment maintenance, the customer affected needs to be informed. The TCM system has to publish messages for another system to generate mail-shots, or emails or to telephone the affected customers.
A Planned Outage may be cancelled or the start times and end times may change due to unavoidable circumstances. Where this is the case, updated messages need to be published. The TCM system needs also to identify the mail template along with the Interruption times.
5.3.1 Message format
CreatedPlannedOutageNotification, ChangedPlannedOutageNotification and ShowOutageRecord message types have the same message formats as shown below. Document.documentType
Document.AliasName
Document.revisionNumber
Document.documentStatus
Document.title
https://www.doczj.com/doc/2b6672365.html,ments (free text comments)
Document.createdBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.createdDateTime
Document.modifiedBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.modifiedDateTime
OutageNotification.MailShotTemplatID
OutageNotification.NumberOfCustomersNowOffSupply
OutageNotification.reason (utility specific concise text description
[0..*]
CustomerAffected.ErpAddress
CustomerAffected.ErpContact
[0..*]
InterruptionNotification.StartDateTime
InterruptionNotification.EndDateTime
GetOutageNotification, CanceledOutageNotification, ClosedOutageNotification and DeletedOutageNotification identify only the documents
5.4 Call Back
When making a trouble call some callers request for CallBacks at a certain point in the restoration phase. CallBack message lists customers requiring call back and when to call back.
5.4.1 Message format
The format for the CreatedCallBack or ShowCallBack or ChangedCallBack is given below. Document.documentType
Document.AliasName
Document.revisionNumber
Document.documentStatus
Document.title
https://www.doczj.com/doc/2b6672365.html,ments
Document.createdBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.createdDateTime
Document.modifiedBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.modifiedDateTime
CallBack.OutageRecord.AliasNames
CallBack.OutageRecord.Reason
CallBack.Remarks
[0..*]
CallBackCustomers.ErpAddress
CallBackCustomers.ErpContact
CallBackCustomers.WhenToCallBack
5.5 Outage Follow-Up Event
Call centre agents need to answer any enquiry from a customer regarding an outage. An OutageRecord has associated Remarks or Follow-up to list chronologically all the actions/events occurred during the restoration of the outage. This helps to monitor the progress of the outage and provides updates to custom er enquiry, TCM produces OutageFollowUpEvent for each action/event associated with the outage.
5.5.1 Message format
The message format for CreatedOutageFollowUpEvent or ShowOutageFollowUpEvent is as follows
Document.documentType
Document.AliasName
Document.revisionNumber
Document.documentStatus
Document.title
https://www.doczj.com/doc/2b6672365.html,ments)
Document.createdBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.createdDateTime
Document.modifiedBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.modifiedDateTime
OutageFollowUpEvent.OutageRecord.AliasNames
OutageFollowUpEvent.OutageRecord.Reason
OutageFollowUpEvent.EventDescription
5.6 Regulatory Standard Violation Warning
If the restoration time for an outage goes over a time limit specified by the regulatory st andard, the customers affected beyond the specified time have to be compensated. This forces the electric utilities to restore supply to as many customers as soon as possible. Some utilities want the TCM system to warn the dispatcher prior to the violation of the regulatory standard.
5.6.1 Message format
The message format for CreatedRegulatoryStandardViolationWarning or ShowRegulatoryStandardViolationWarning is as follows
Document.documentType
Document.AliasName
Document.revisionNumber
Document.documentStatus
Document.title
https://www.doczj.com/doc/2b6672365.html,ments
Document.createdBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.createdDateTime
Document.modifiedBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.modifiedDateTime
RegulatoryStandardViolationWarning.OutageRecord.AliasNames RegulatoryStandardViolationWarning.OutageRecord.Reason RegulatoryStandardViolationWarning.AlarmDescription RegulatoryStandardViolationWarning.TimeLeft
5.7 Customer Outage History Message Types:
Outage History allows utilities to examine the number of outages suffered by a customer. This also provides data to calculate the total supply interruption to any customer over a given period.
5.7.1 Message format
ShowCustomerOutageHistory has the following format.
Document.documentType
Document.AliasName
Document.revisionNumber
Document.documentStatus
Document.title
https://www.doczj.com/doc/2b6672365.html,ments
Document.createdBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.createdDateTime
Document.modifiedBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.modifiedDateTime
CustomerOutageHistory.ErpAddress
[0..*]
OutageHistoryDetail.OutageRecord.AliasNames,
Outage.HistoryDetail.OutageRecord.Reason
OutageHistoryDetail.FaultAddress
OutageHistoryDetail.StartDateTime
OutageHistoryDetail.Type
OutageHistoryDetail.VoltageLevel
OutageHistoryDetail.RestoredDateTime
OutageHistoryDetail.NoOfCustomersAffected
OutageHistoryDetail.ActualFault
5.8 Customer Connection
*** Add description
5.8.1 Message Format
CreatedCustomerConnection or ShowCustomerConnection has the following format Document.documentType
Document.AliasName
Document.revisionNumber
Document.documentStatus
Document.title
https://www.doczj.com/doc/2b6672365.html,ments
Document.createdBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.createdDateTime
Document.modifiedBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.modifiedDateTime
ConnectionRequest.ErpAddress
ConnectionRequest.ErpContact
ConnectionRequest.Type
5.9 ServiceExtension Request
Network extension request may arise due to new supply or new development.
5.9.1 Message Format
CreatedServiceExtensionRequest or ShowServiceExtensionRequest has the following message format
Document.documentType
Document.AliasName
Document.revisionNumber
Document.documentStatus
Document.title
https://www.doczj.com/doc/2b6672365.html,ments
Document.createdBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.createdDateTime
Document.modifiedBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.modifiedDateTime
Service ExtensionRequest.ErpAddress
Service ExtensionRequest.ErpContact
Service ExtensionRequest.Location
Service ExtensionRequest.Description
5.10 Extension Project Record
A network extension request undergoes various processes to create a ServiceExnsionProjectRecord.
Other message types associated with a Service Extension Request e.g. LoadDataSet, LandBaseDataSet, ServiceExtensionProjectDetails ServiceExtensionProjectCost, ExtensionProjectApproval are covered in IEC61968-Part7
5.10.1 Message Format
CreatedExtensionProjectRecord or ShowExtensionProjectRecord has the following format Document.documentType
Document.AliasName
Document.revisionNumber
Document.documentStatus
Document.title
https://www.doczj.com/doc/2b6672365.html,ments
Document.createdBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.createdDateTime
Document.modifiedBy.Person.*
https://www.doczj.com/doc/2b6672365.html,anisation.*
Document.modifiedDateTime
ServiceExtensionProjectRecord.ErpAddress
ServiceExtensionProjectRecord.ErpContact
ServiceExtensionProjectRecord.Location
ServiceExtensionProjectRecord.Description
ServiceExtensionProjectRecord.ProjectDetails
ServiceExtensionProjectRecord.ProjectStatus
[0..*]