1409   MIssing info on when a setting was changed

Created: 11 Jun 2015

Status: In Force (green)

Part: Part 7-3 (2010; Edition 2)

Links:

Page:

Clause:

Paragraph:

Category: Issue for edition 3 of this part

Issue

In the DER world with multiple clients accessing the same resource, it's valuable do have the info on when a setting was last changed.

As the setting type of CDC (ING, ASG, SPG, etc) does not include a timestamp, the workaround is that each client set up a report that gets triggered on settings change.

But clients that are not online, when the change takes place, will not get this knowledge. Neither does new clients.

This info needs to be available on server side.

Proposal

Add a 'name=t, type=Timestamp, FC=ST, MOC=M' attribute to ING, ASG, SPG, etc

Discussion Created Status
No change needed 26 Apr 18 In Force (green)
Can we close that with no change needed? 12 Oct 16 Ballot Period
Have a look into part 7-2 table 26. It contains the enumeration of all services which can be tracked. For modifying an SP setting, it is the service SetDataValues.
The control block related services appear prominent because they also track the values of the control blocks needing enhanced CDCs. 		04 Nov 15 Discussion (red)
In the specific use case we do not use setting group, though we have other use cases where setting group may be implemented.

Basically, we just need the information about when a setting was changed, but I can foresee that having the information about who changed it could also be valuable.

Reading clause 14.2 again, I see the note that "The model can be used to track any service request." but being mentioned within the description of control block service tracking, it is fair to assume that what is meant is "any service requests on control blocks"

It is not exactly clear that tracking can be used with services beyond those working with the control model and control blocks. 		02 Nov 15 Discussion (red)
I agree that the requirement is not clear - what is t supposed to display?
1) if the setting is in a setting group, the setting groupo displays with the LActTm the time when the group changed. i.e. the last change/update of the setting.
There is few added value here to add a t for each of the settings as it will be aligned with the LActTm.
2) When was the last change of the setting via the SE buffer? This is covered by the Tracking service.
3) The setting is not in a setting group - SP - then setVal has a dChg trigger option and it changes can be reported. t is available at the ReportT Time Of Entry + in the tracking of the change of the SP setVal. Here an extension may be considered, for the next edition; however workarounds already exist. 		22 Oct 15 Discussion (red)
If the key requirement is, that any Client knows the date of the last Setting Change (and does not Need to know who changed it), I would Support the adding of an Attribute t.

However, if the requirement is, that any Client shall as well know the history of Setting changes, I agree that we can use the tracking Services and do not need a t attribute 		21 Oct 15 Discussion (red)
The tracking model allows to track all services - see IEC 61850-7-2 clause 14, especially 14.2. The serviceType includes the setting group related services as well as the read/write services on settings with FC = SP. 20 Oct 15 Discussion (red)
I don't agree.

It seems that the tracking model is only applicable with control blocks and controllable objects. Not with settings.

So an additional timestamp IS needed. 		15 Oct 15 Discussion (red)
I agree with Wolfgang
LTRK.GenTrk gives you the information regarding to
which setting (objRef) has been
successfuly (errorCode) changed
when (t)
by who (originatorID)
07 Jul 15 Discussion (red)
For this purpose an additional time stamp attribute is not needed. Use service tracking for write commands and SGCB related services to get this info, for clients not permanently connected via buffered reporting or even better via logging.
The tracked service contains not only the time stamp, but also the ID of the originator of the setting request.
If needed, also the reporting/logging of the written value together with the write service is possible at least for parameters with fc=SP. 		11 Jun 15 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1