AMI -ENT Service Definition Team Step-by-Step Modeling and Artifacts Generation Process.

AMI -ENT Service Definition Team

Step-by-Step Modeling and Artifacts Generation Process

Information Online

• AMI-Ent Service Definitions Sub-Team– http://www.smartgridipedia.org/index.php/AMI-

ENT_Service_Definitions_Sub-Team

• Step-by-Step Modeling and Artifacts Generation Process– http://www.smartgridipedia.org/images/a/af/AMI_ENT_Step-By-

Step_Modeling_and_Artifacts_Generation_Guidelines.doc

Overall Process

• Business process analysis

• Integration requirements detailed in sequence diagrams

• Service and operation pattern applied

• Service and information object identification and harmonization

• Data modeling and artifacts generation

• Artifacts validation and testing

• Artifacts version control and issue tracking

Step 1 – Business Process Analysis

Step 1 – Business Process Analysis

• Step 1 Summary

– Business processes of AMI-ENT use cases are captured in UML activity diagrams.

– The processes are re-examined for gap analysis in terms of industry standards as well as integration requirements.

– These activity diagrams are the start point for detail service design

Step 2 – Integration Requirements Detailed in Sequence Diagrams

• Integration with ESBsd Integration Sequence Diagram - B1S1

AMI Head End

(from Actors - Set 2)

Meter Data ManagementSystem (Enterprise)


ESB

CreatedMeterReading()

Acknowledgement()


Acknowledgement()


• Integration without ESB or transparent ESBsd Integration Sequence Diagram - B1S1

AMI Head End





Acknowledgement()


• Step 2 Summary

– Sequence diagram provides a mechanism to: • Describe integration between message providers and

consumers in terms of message transaction in this example. • It presents messages in sequence base on integration

requirements identified in Step 1)

Step 3 – Service and Operation Pattern Applied

• Service Pattern (for Web services naming convention)– Send – to provide (send) information (business object) for public (enterprise)

consumption. To be invoked by the system of record for the business object and only when the state of the business object has been changed.

– Receive – to consume (receive) information (business object). – Request – to request another party to perform a specific service – Execute – to run a service provided to the public, which may include a state

change request or a query request. – Reply – to reply with the result of the execution of a service (by the Execute

service) – Show – to provide (show) information (business object) for public (enterprise)

consumption, when the state of the business object is not changed, by the system of record or other system that has a copy of the same business object.

– Retrieve – to request specific data of a business object to be provided. – Publish – to provide (send) information (business object) for public (enterprise)

consumption. To be invoked by the system of record for the business object and only when state of a business object has changed.

– Subscribe – to consume (receive) information (business object) from an external source.


• Operation Pattern (for service operation naming convention)– Create – operation: used in Request, Execute services– Change – operation: used in Request, Execute services– Cancel – operation: used in Request, Execute services– Close – operation: used in Request, Execute services– Delete – operation: used in Request, Execute services

– Created – operation: used in Send, Receive, Reply services– Changed – operation: used in Send, Receive, Reply services– Canceled – operation: used in Send, Receive, Reply services– Closed – operation: used in Send, Receive, Reply services– Deleted – operation: used in Send, Receive, Reply services

– Get – not used, equivalent to Retrieve service– Show – used as the service level pattern. – Reply – used as the service level pattern. – Subscribe – used as the service level pattern. – Unsubscribe – not used.


Service/operation naming convention

• Service naming convention: – <Information Object>

• if no ESB involved or ESB invisible such as MeterReading– <Service pattern name> + <Information Object>

• if ESB is involved such as ReceiveMeterReading

• Operation naming convention: – <Operation pattern name> + <Information Object>

• for both integration scenarios such as CreatedMeterReading

sd Integration Sequence Diagram - B1S1

AMI Head End




ESB


Acknowledgement()


Acknowledgement()


Example after a pattern is applied (Integration with ESB)

WS

WS


Two MEPs supported:1) Two way2) Call back

Note One-way pattern is not supported by AMI ENT service definition meaning there should be always SOAP level message return (not just HTTP level).

Step 4 – Service and Information Object Identification and

Harmonization

http://www.smartgridipedia.org/images/5/52/AMI_ENT_Service_Inventory.xls

Step 4 – Service and Information Object Identification and

Harmonization

• Step 4 Harmonization

– Service identification is a critical step in the overall service design process.

• It is not just driven off of the business process analysis in Step 1) but also based on data information model and in accordance with business functionalities.

• Identified services are listed in a service inventory sheet. • Harmonize services so that granularity level of services and information

objects can be determined, • Overlapped services can be eliminated• Services well aligned with business process

Step 5 – Data Modeling and Artifacts Generation

• Information objects documented after Step 4) are modeled in UML using Sparx EA. The UML model is created in the following layered structure:

– Reference Models (CIM, Multispeak, & etc.)– Semantic Model– Context Model (AMI Ent Profile)– Implementation Model (XSD)


• Reference Model– IEC61970cim14v11_IEC61968cim10v25_Combined

class MeteringOv erv iew

ComFunction

+ amrAddress: String [0..1]+ amrRouter: String [0..1]+ twoWay: Boolean [0..1]

Identi fiedObjectDemandResponseProgram

+ type: String [0..1]+ validi tyInterval: DateTimeInterval [0..1]

AssetFunctionDeviceFunction

+ disabled: Boolean [0..1]

ElectricMeteringFunction

+ bil l ingMultipl ier: Float [0..1]+ bil l ingMultipl ierApplied: Boolean [0..1]+ currentRating: CurrentFlow [0..1]+ demandMultipl ier: Float [0..1]+ demandMultipl ierAppl ied: Boolean [0..1]+ kWhMultipl ier: Integer [0..1]+ kWMultipl ier: Integer [0..1]+ transformerCTRatio: Float [0..1]+ transformerRatiosApplied: Boolean [0..1]+ transformerVTRatio: Float [0..1]+ voltageRating: Voltage [0..1]

AssetContainerEndDev iceAsset

+ amrSystem: String [0..1]+ demandResponse: Boolean [0..1]+ disconnect: Boolean [0..1]+ dstEnabled: Boolean [0..1]+ loadControl: Boolean [0..1]+ metrology: Boolean [0..1]+ outageReport: Boolean [0..1]+ readRequest: Boolean [0..1]+ relayCapable: Boolean [0..1]+ reverseFlowHandl ing: Boolean [0..1]+ timeZoneOffset: Minutes [0..1]

Identi fiedObjectEndDeviceControl

+ drProgramLevel: Integer [0..1]+ drProgramMandatory: Boolean [0..1]+ priceSignal: FloatQuanti ty [0..1]+ scheduledInterval: DateTimeInterval [0..1]+ type: String [0..1]

Activi tyRecordEndDeviceEv ent

+ userID: String [0..1]

Identi fiedObjectEndDeviceGroup

+ groupAddress: Integer [0..1]

IntervalBlock

MeasurementValueIntervalReading

+ value: Float [0..1]

MeterAsset

+ formNumber: String [0..1]+ kH: Float [0..1]+ kR: Float [0..1]

Identi fiedObjectMeterReading

+ valuesInterval: DateTimeInterval [0..1]

WorkMeterServ iceWork

Pending

+ multiplyBeforeAdd: Boolean [0..1]+ offset: Integer [0..1]+ scalarDenominator: Integer [0..1]+ scalarFloat: Float [0..1]+ scalarNumerator: Integer [0..1]

MeasurementValueReading

+ value: Float [0..1]

ReadingQuality

+ qual i ty: String [0..1]

Identi fiedObjectReadingType

+ channelNumber: Integer [0..1]+ defaultQuali ty: String [0..1]+ defaultValueDataType: String [0..1]+ dynamicConfiguration: String [0..1]+ intervalLength: Seconds [0..1]+ kind: ReadingKind [0..1]+ multipl ier: UnitMultipl ier [0..1]+ reverseChronology: Boolean [0..1]+ unit: UnitSymbol [0..1]

Identi fiedObjectRegister

+ leftDigitCount: Integer [0..1]+ rightDigitCount: Integer [0..1]

LocationSDPLocation

+ accessMethod: String [0..1]+ occupancyDate: AbsoluteDate [0..1]+ remark: String [0..1]+ siteAccessProblem: String [0..1]

Identi fiedObjectServ iceDeliveryPoint

+ bil lingCycle: String [0..1]+ budgetBi ll : String [0..1]+ checkBil l ing: Boolean [0..1]+ consumptionRealEnergy: RealEnergy [0..1]+ ctptReference: Integer [0..1]+ estimatedLoad: CurrentFlow [0..1]+ grounded: Boolean [0..1]+ loadMgmt: String [0..1]+ nominalServiceVoltage: Integer [0..1]+ phaseConfig: PhaseConfigurationKind [0..1]+ ratedCurrent: CurrentFlow [0..1]+ ratedPower: ActivePower [0..1]+ serviceDel iveryRemark: String [0..1]+ servicePriori ty: String [0..1]

+ReadingQuali ties0..*

+IntervalReading 1

+SDPLocations 0..*

+ServiceDel iveryPoints 0..*

+ReadingType 0..1

+Register 0..1

+Pending

0..1

+ReadingType

1

+IntervalBlocks

0..*

+ReadingType

1

+Readings

0..*

+ReadingType

1+ReadingQual i ties0..*

+Reading0..1

+EndDeviceAsset

0..1 «informative»

+Readings

0..*

+IntervalBlocks0..*

+Pending

0..1

+IntervalBlocks

0..*

+MeterReading0..1

+MeterAsset0..1

+MeterReadings

0..*

+Readings0..*

+MeterReadings

0..*

+MeterReplacementWorks

0..* +OldMeterAsset 0..1

+MeterReadings0..*

+ServiceDel iveryPoint0..1

+IntervalBlocks0..*

+IntervalReadings

0..*

+EndDeviceEvents

0..*

+DeviceFunction0..1

+DemandResponseProgram1

«informative»

+EndDeviceGroups0..*

+MeterReading

0..1

+EndDeviceEvents0..*

+DemandResponseProgram

1+EndDeviceControls0..*

+EndDeviceGroup0..1

+EndDeviceControls

0..*

+ServiceDel iveryPoint0..1

+EndDeviceAssets

0..*

+EndDeviceGroups 0..*

+EndDeviceAssets0..*

+EndDeviceControls

0..*

+EndDeviceAsset

0..1

+EndDeviceAsset

0..1+DeviceFunctions

0..*

+Registers0..*

+DeviceFunction0..1

+MeterServiceWorks

0..* +MeterAsset 0..1

Mainly based upon Metering package


• Context (AMI-ENT profile) – Entity diagram

MD3i SB Context Diagram

CustomerAgreement

EndDev iceEv ent

Interv alBlock

MeterAsset

Reading

MeterReading

Serv iceDeliv eryPoint

ReadingType

ReadingQualityPending

Interv alReading

Status

+ReadingQualities0..*

1

11

+ReadingQualities

0..*0..1

+IntervalReadings

0..*

0..1

0..1

+EndDeviceEvents

0..*

+IntervalBlocks 0..*

1

+Readings

0..*

0..1


• Context (AMI-ENT profile) – Property diagrams

MD3i SB Context Diagram

ReadingType

aliasName

channelNumbername

mRID

defaultQualityinterv alLengthdefaultValueDataType rev erseChronology

unitSymbol

dynamicConfiguration

multiplierdescription

kindReading

1

0..1

1

0..1

1

0..1

1

0..1

1

0..1

1

0..1

1

0..1

1

0..1

1

0..1

1

0..1

1

0..1

1

0..1

1

0..1

Step 5 – Data Modeling and Artifact Generation

• Step 5 Summary

– IEC CIM based– UML profile fully utilized – Precise definition on messages (entities & properties)– Model driven XSD generation

Step 6 – Artifacts Validation and Testing

• XSD and XML validation– Message schema (XSD) validation– Message instance (XML) validation against XSD

• CIM Compliance Testing– Generate an XML payload using CIM Part-9 XSD and then

validate this XML against AMI Ent XSD if such XSD exists


• WSDL Validation– WSDL well-formedness validation (both W3C XSD & WSDL)– WSDL WS-I compliance validation

• WSDL Style:– Wrapped document literal– Rewrap root XSD element to avoid wire signature issue– MTOM for large payloads (SOAP attachment a discussion point)– Restful service not utilized but a discussion point


• Web Service Testing

– After the validation web services can be created and tested according to their WSDL definitions using open source applications such as Apache Axis2.

– Service pattern name can then be updated and tested based on integration needs such as with or without an ESB.


ServiceName


MeterReading

Step 7 – Artifacts Version Control and Issue Tracking

• XSD Version Control:

– There are two scenarios for an XSD version update:• Major version update

– It means major update has been made in an XSD and its backward compatibility has been broken as a result.

• Minor version update– It means its backward compatibility is held. One example of such minor

update is a new element added but as optional.

– By naming convention, XSD targetNamespace and version attribute are defined as:

• targetNamespace=“http://www.smartgridipedia.org/2009/09/MeterReading”

• version="<Major version>.<Minor version>".


• WSDL Version Control:

– An XSD is imported in a WSDL for data type definition. As a result, at least two namespaces (XSD & WSDL) exist in a WSDL definition as shown below:

• targetNamespace="http://www.smartgridipedia.org/2009/09/MeterReading.wsdl"

• xmlns:typeOrig="http://www.smartgridipedia.org/2009/09/MeterReading"

– By convention, WSDL targetNamespace needs to be updated whenever a change occurs to an XSD namespace. In other words, a major XSD update will result in a WSDL namespace change and minor XSD update (no namespace change) will have no impact on WSDL namespace.


• Issue Tracking

http://osgug.ucaiug.org/sgsystems/SDTeam/Lists/Service%20Definition%20issues/AllItems.aspx

Questions & Comments

AMI -ENT Service Definition Team Step-by-Step Modeling and Artifacts Generation Process.

Documents

Transcript of AMI -ENT Service Definition Team Step-by-Step Modeling and Artifacts Generation Process.