384   Conceptual service model in 5.3

Created: 12 Sep 2006

Status: In Force (green)

Part: Part 7-2 (2003)

Links:

Page: 018

Clause: 05.3

Paragraph: Figure 3

Category: Issue for edition 2 of this part

Issue

The Log class is depicted as associated with the logical device. Actually it is associated with the LLN0.

Proposal

Correct drawing to show association with LLN0.

Discussion Created Status
Changed status to green.

Followed Wolfgang Wimmer's proposal (see below).

Comments from Wolfgang Wimmer dated 2007-01-10:

Hello Karl-Heinz,
if the solution described by you is the only solution, and 'efficiency of modeling' is an important criterium, I can accept your proposal as described below, especially because it is on service level compatible with the current solution. However this means, that in your new 7-2 proposal in Figure 3 the containment relation of the log object should ONLY be to the LN, and NOT to LD and server.
Further it means, that the log query option you added to the server level directory service has to be removed again.

Just note, that having multiple logs in each LN also needs an add-on to SCL.

Explanation from Karlheinz dated 2007-01-09:
Hello Wolfgang,

The crucial requirement is: allow multiple Logs in an IED. We have requirements to allow many Logs.

The following is a first brief response on Wolfgang's statements. More discussions and more details may be needed.

Solution today: use multiple LDs.
--------------------------------------------------
This is quite inefficient when we need several LDs just to provide a scope for further Logs.

One LD: Suppose we have a LD A for control and monitoring of a wind turbine: LD "WPP". We want to have different Logs for different information with different arrival rates. One rate could be 10 X-events per day (keep log entries for one year), another 10 Y-event per minute (keep log entries for one week), ... With one Log it would require to log all X and Y log entries!! It would be much more efficient to separate the two streams of log entries.

Two LDs: We could define a first LD A and a second LD B to host the Log for X and Y logs. LD A could contain all LNs for control an monitoring and Log X. LD B could contain just LLN0 with Log Y and LPHD.. The same way we could add more LDs if we need more Logs because of different event streams.


Resume: Creating an almost empty LD just for a single Log seams to require a lot of resources (multiple LLN0s and LPHDs).

There are two other general issues with Logs: (1) Filtering and (2) historical statistical information.

(1) Filtering
Currently we could in ACSI just query ALL log entries by time. If we use multiple data objects for the multiple streams X and Y, we could not filter them! MMS journals allow filtering. Filtering would be required in any case ... this is what we have added in the wind power standard IEC 61400-25-3.

(2) Historical statistical information
For each kind of statistical data (Mean, Max, Min, Avg, ...) we need a specific instance of a LN. It would be an advantage to have the statistical data and the historical in the same LN.
Anyway, historical statistical data will generate a lot of logs ...


Proposed Solution with one LD:
--------------------------------------------
An option could be to just allow Logs to be contained in each LN. This would not require additional resources ...

Then we may not need the Log to be defined at Server level. Because LD0/LLN0 or any other LD0/LN could be used to host the log information for the whole IED.

Note that we are "opening" IEC 61850
11 Feb 07 In Force (green)
Please see proposal on new diagram by the editors' group in Tissue #456. 23 Dec 06 Ballot Period
By the way, having several LOGs within an LD leads to a new SCL version which is in this respect incompatible to the current version. 11 Dec 06 Discussion (red)
I see no reason, why there should be more than 1 Log per LD (i.e lets keep 1 LOG in LLN0). If several logs are needed, you can have several LDs on a server. Further, several LCBs can write different data to the same log (other LCBs could write into another log on another LD). This is possible because LCB data sets can reference data in all LDs. Therefore it would also be sufficient to have LCBs in LLN0 only. Just for consistency to reporting it might be considered to have them also in other LNs... 11 Dec 06 Discussion (red)
Additional issue: The multiplicity of LOG should be [0..n]. In many cases it is not sufficient to have one LOG only.

Moving the LOG to LN class would allow to have more than one LOG per logical device (one per LN). But it would not be possible to have more than one in LLN0.
08 Dec 06 Ballot Period
Set to final proposal.

Associate LOG AND LOG Control Block (LCB) with LN class. LCB is already associated with LN class.

Requires changes in Figure 3, clause 14.3.3.2.1, and in table 15.
08 Dec 06 Ballot Period
We should not restrict LOG Control Blocks to be associated only with LLNO. 14 Sep 06 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1