Minutes ETC meeting, December 21st and 22nd, 2005
Date: Wednsday December 21st and Thursday December 22nd, 2005
Time: 10:00 - 18:00 (?) 9:00 - 16:00 (?)
Meeting place: Energinet.dk, Copenhagen, Denmark
Participants: Christian Odgaard, Eltra, DK
Hugo Dekeyser, UMIX, BE
Jon-Egil Nordvik (Convenor), Statnett, NO
Kees Sparreboom, TenneT, NL
Lucy Sarkisian, TenneT/EBO, NL
Ove Nesvik (Secretary), EdiSys, NO
Attachment: None
1) Approval of agenda
The agenda was approved with some changes to the sequence of the items (item 7 and 9 was taken as item 3 and 4).
2) Minutes from previous meetings
Approved
3) ebIX architecture
The item started with a discussion, taking a “bird’s perspective” over what we are doing, trying to find the important parts of what we are doing. I.e. discuss how we shall proceed to get as many deliverables as possible ready before next ebIX Forum meeting. The ultimate goals of the ebIX work are making the physical power system work (i.e. planning and operation) and making the actors able to invoice their services.
One of the main parts of the ebIX architecture will be the ebIX/EFET/ETSO Harmonised role model. The Role model consists of roles, domains, installations (?) and associations. Hugo explained that there are two basically different types of roles; the administrator roles for the domains and the operational roles. Kees informed that also EASEE-Gas is starting up a project for making a new role model for Gas.
A conclusion from the discussions was that we need a non technical document explaining the concept of the Harmonised role model. The document will be used to convince other parties, countries, etc that the Harmonised role model should be the basis for all developments in the area where ebIX is working. Hugo stressed the need for making our models more abstract in the beginning and then on a later stage use these abstract models for making the detailed parts (e.g. change of Balance responsible and change of Metered data collector).
Hugo showed some examples of how he sees abstract modelling in MagicDraw. However Hugo has found some problems in MagicDraw, which MagicDraw has promised to fix in their next version. The principle is making abstract processes based on UMM transaction patterns and combining these with the roles and Core Components (ACC/ABIE, QDTs etc).
Kees draw the architecture on the black board, which includes the following parts:
o The Role model.
o The Core Components. ebIX has made the first versions of the QDTs, but need to define the ebIX ACC/ABIES.
o The Code lists.
o The UMM transaction patterns. ebIX has to define the abstract ebIX patterns (templates) based on these.
o Class diagrams (Business documents) for many of the messages that will be exchanges within the energy sector are made, e.g. 392/414 (for change of attributes connected to a MP).
o We will make Business process models based on the above mentioned components. These will consist of UseCases, Activity diagrams taken from the templates, Sequence diagrams taken from the templates and Class diagrams based on the common set of data needed for a certain role (e.g. defined in the E07, Master data for a MP).
o The Class diagrams will be mapped according to the ebIX Methodology to syntax specific messages, such as EDIFACT, XML or SOA (Service Oriented Architecture).
However, we still have some unsolved questions related to the linking between the different components (diagrams), e.g. what kind of message (arrow) should be used in the sequence diagram (send, signal, ..).
Hugo suggested (once again) that ebIX should get a verification of the above ideas from an UML expert. Several possible experts were suggested, both from MagicDraw, UN/CEFACT and general UML environments. Hugo and/or Kees promised to take a first contact with an expert from the general UML environments before next meeting and maybe invite her/him to our next meeting. Jon-Egil and Hugo will try finding a budget for the consultancy.
4) BRS (Business Requirements Specification) for a subset of one of the ebIX models to UN/CEFACT
The item was postponed until meeting, since the ebIX architecture not is clear enough.
5) Generic ABIEs
The ebIX CC registry 0.5.F was reviewed:
o The package for LocalMeteringPointCharacteristics was agreed
o The ABIE registry was compared with the EMD ABIEs and missing ABIEs was added.
Homework:
o Ove will merge the CC registry and the Code lists
o Ove will send a mail to relevant UN/CEFACT members and ask for their opinion of the following ABIEs:
6) Update of the ebIX Domain model
Postponed until an UML expert is available, i.e. next meeting.
7) Review of the ebIX Methodology
Due to lack of time the item was postponed.
8) Status questions to MagicDraw from Kees related to modelling of processes and areas
The following answer was received from MagicDraw on Kees questions:
- Activity diagrams should be used for processes modelling, not Collaborations (see business process diagram in MD 10.0)
- Tags should be used instead of constraints (sector, reason, role, function should be declared as tag definitions and real different values should be assigned on every element)
- All these tags can be declared in one stereotype
- The same stereotype can be applied to all elements in subsystem
- Parameters can be declared in operation or in behaviors (activity, interaction), so you are able to call/trigger entire Activity (activity diagram) and pass any argument values
Further explanations will be invoiced from MagicDraw on consultancy basis.
The answers don't bring ETC much further for the time being and the next step will be contact with an UML expert (se item 3 above).
9) Request from the Nordic railway authorities for a model for train settlement
The following text was added to the railway business information model document:
“ebIX has verified this business information model for train settlement, but the responsibility for further developments stays within the railway sector and not within ebIX.”
The item will be reopened at the next ETC meeting if asked for by anybody.
10) XML documents
Kees had as homework made a proposal for the CodeList xsd’s. This will be published under a work area on www.ebix.org.
Continuous homework:
o Ove will verify the usage of Complex types and attributes in the QDT xsd, i.e. how to define the enumeration for Product using two enumerations (product and code list responsible).
o Ove will make a proposal for the QDT xsd and ABIE xsd.
11) Review of proposal for ebIX code lists from Kees
Kees had distributed a MagicDraw code list based on the ebIX Word code list. Kees has marked all clearly national codes with the documentation “Assigend to …” and copied them into separate national code lists. Kees has used tagged values for characteristics of the codes, such as Description, Responsible role, Type etc. Kees has also made xml schemas for all the code lists.
Further actions:
o Adding UIDs (Unique identification) for all BBIE, ABIE, ASCC and adding a “Code list ID” for all Code lists. The UID and code list ID will be added to these elements as tagged values, i.e. as a UID (used both for the UID and the Code list ID) and a Version.
o All tagged values for the codes, except “Documentation”, will be based on enumeration literals.
o National code list should have national code list responsible identifications. These should be asked for at UN/CEFACT as DMRs. ETC will make DMRs for national code list responsible identification for those countries wanting it.
Homework:
o Kees will create an Excel sheet containing the UID, Version and object type and publish it on www.ebix.org.
o Kees will add the tagged values related to the UID to the code lists.
o Ove will add the tagged values related to the UID to the other CCs.
12) Mapping of Class diagrams from EMD and CuS to EDIFACT and XML?
· Proposal for mapping the EMD class diagrams (Kees)
· Proposal for mapping the CuS class diagrams (Hugo)
13) Maintenance
Code request from Sweden:
· A code meaning "start-of-supply" corresponding to the code E20 "end-of-supply".
Sweden will use E20 to be able to terminate a supply due to lack of payment from customer. To start up again Sweden need the code for "start-of-supply". The request is related to Reason for Transaction.
Conclusion: ETC believe this is a change in connection status and not a reason for transaction. It should be sent in CCI/CAV with the codes connected or disconnected.
· A code meaning "customer is dead" (information to/from BS/MDR to be aware that customer is dead). The request is related to Reason for Transaction.
Conclusion: ETC propose making a new attribute for the Party connected to grid, i.e. “Status for Party connected to grid”. Code values could be “Dead”, “Bankrupt”, “Temporarily inhabited” etc.
· A new code in CCI/CAV to be able to send "Number of objects (MPs)". The request is related to “time series characteristics” (UTILTS).
Conclusion: The request is related to metered data and must be addressed to EMD.
Homework:
o Related to the "start-of-supply" above Hugo will make a state diagram with the states a MP can have.
o During the discussions Kees promised to take a review of the reason for transaction codes and make a proposal to be reviewed on the next ETC meeting.
14) Information
No reports.
15) Next meeting(s)
· February 22nd and 23rd 2006, Oslo - Note that the dates are changed!
· April 4th and 5th 2006, the Netherlands
16) AOB
No items.
Appendix A Participants in ETC
Name / Company / Telephone / Mobile / E-mailCarl Major / E.ON Netz / +49 5132 88 2179 / +49 172 5109881 /
Christian Odgaard / Energinet.dk / +45 76 22 44 63 / +45 23 33 85 55 /
Hans Montelius / SvK / +46 8 410 802 82 /
Hugo Dekeyser / Umix / +32 2 518 65 87 / +32 4 77 5580 03 /
Jon-Egil Nordvik (Convenor) / Statnett / +47 22 52 70 00 / +47 975 36 303 /
Kees Sparreboom / TenneT / +31 622 66 7911 /
Lucy Sarkisian / TenneT / +31613 643 092 /
Matti Vasara / Fingrid / +358 405 19 5017 /
Ove Nesvik (Secretary) / EdiSys / +47 22 42 13 80 / +47 928 22 908 /
Adrian Fuchs / Etrans / +4158580 2111 /
Terje Nilsen (Observer) / Nord Pool / +47 67 52 80 44 / +47 930 34 100 /
Appendix B Work items for ETC
· Implement the ebIX architecture, including:
o Review of the ebIX Domain model
o Defining ebIX CCs
o Review of the ebIX code lists
o Creation of ebIX EDIFACT documents (EMD and CuS)
o Creation of ebIX XML-documents
· Restructuring of UTILTS and UTILMD
· Review of the ebIX Methodology
ETC - ebIX Technical Committee Page: 7