DLMS Activity Calendar CIMA / SIERRA

www.daq-iot.com  [email protected]

__________________________________________________________

1.1 Activity Calendar

The activity calendar class is typically used to handle different tariffication structures. It is a definition of scheduled actions inside the meter, which follows the classical way of calendar based schedules. It can coexist with the more general COSEM class schedule and can even overlap with it (not used in CIMA). The activity calendar defines the activation of certain scripts (see COSEM class [id:9] Script Table), which can perform different activities inside the meter. CIMA / SIERRA: No real scripts are implemented in CIMA / SIERRA. Instead, the state of the 16 signals TOU1..TOU16 in Tariff Application (see  Tariff Application) are set.

This class has two calendar tables which are marked with the suffix “_active” and “_passive”. Their attributes are identical and therefore they are described only once in this document.

After a power failure, the TOU signals must be set to the current state as required by the calender. There is no need to run over all states that were due during the power failure.

The activity calendar allows references for special days as defined in Monitor Register.

Attribute Description

The attributes with the suffix “_active” are those which are normaly used when the meter is in operation; attributes with the suffix “_passive” will be used after they are activated. Activation occurs when the current date equals or exceeds the commuting date (ActivatePassiveCalendarTime).

calendar_nameType: octetstring[8]

Typically contains an identifier, which is descriptive to the set of scripts which are activated by the object. This attribute is used by the firmware only for display and readout. If the activity calendar is included in the readout or display list, the active calendar_name will be displayed (also known as TOU id).

season_profileType: Array[12] of Season

Contains a list (array) defining seasons, classified by their starting dates. Each season has a reference to a table of weekly profiles. The season_profile list is sorted according to season_start: earlier dates come first. With this attribute, a calendar year is subdivided in seasons which differ by the week_profile they activate. Each element of the season_profile array is structured as follows:

season_profile_name Type: octetstring[1]

A octetstring containing a user defined name for identifying the current season_profile. This attribute is not used by the firmware. Implementation note: The name is restricted to 1 octet. The effective naming shall be resolved by another general mechanism applicable to all names assigned by the user to help identify the meaning of the objects.

season_start Type: UTC

Defines the date in UTC format when a season starts. The end of a season is given by the start of the next season. Implementation note: From the UTC data type only month and day are considered; the other elements are ignored by the firmware, and are read back as “undefined” (usually coded as 0xFF according to COSEM). Wild cards are not allowed for day and month.

UTC: octet-string { year highbyte, year lowbyte, month, day of month, day of week, hour, minute, second, hundredths, deviation, clock status }

Shaded fileds are ignored by the firmware, and are read back as “undefined”.

week_name Type: octetstring[1]

Used to set a reference to the corresponding week_profile selected for the present season. The name chosen must correspond to one given in week_profile_name of attribute week_profile_table. Implementation note: The name is restricted to 1 octet. The effective naming shall be resolved by another general mechanism applicable to all names assigned by the user to help identify the meaning of the objects.

week_profile_tableType: Array[12] of Week_profile

Contains an array holding the day_id for every day of the week that are used for different seasons. A day_id references an entry in the day_profile_table. Each array element of week_profile_table is structured as follows:

Week_profile_name Type: octetstring [1]

Is a user defined name identifying the week profile and is used as link to the attribute season profile (week_name).

Monday .. sunday Type: Unsigned8

Contains a reference (day_id) to the day_profile (of the day_profile_table attribute) valid for the specified day of the week (Monday .. Sunday);

day_profile_tableType: Array[8] of Day_profile

Contains a list, arranged as an array, of day profiles with their corresponding identifiers. It is organized as follows:

day_id: Type: Unsigned8

Is a user defined byte identifying the corresponding day_profile and is used as a reference in the attribute week_profile_table.

day_profile: Type: array[10] of day_profile_action

Each day profile has a list of scripts and the corresponding activation times. Within each day_profile the list is sorted according to start_time. Implementation note: The first entry must start with start_time 00:00.

start_time: Type: time

Specifies the time of day when scripts are executed. Time is an octet string whose format is defined by the COSEM time type [Ref. 2]. The internal resolution of the schedule is the minute, thus the seconds and hundredths are ignored and set to 00 (i.e. writing to these fields is disregarded and the values are read as 00). It is coded as follows:

octet-string {hour, minute, second, hundredths}

Implementation note: Entries have to be sorted by their time of occurrence: earlier entries first. The start time of the first entry of each day profile must always be 00:00. “Empty” or not used days must be placed at the end of the array.

script_logical_name: octetstring [6]

The script_logical_name is used as reference to select the desired script table from the Script Table class (not included in the present version of this document).

Implementation note: No real scripts are implemented in CIMA / SIERRA. Instead, the state of the 16 signals TOU1..TOU16 in Tariff Application is set using the script_selector below. The script_logical_name for all day_profiles is always the same and is set (fixed) to: 00 00 0A 00 64 FF. The firmware ignores the contents of the script_logical_name. Its value must be parameterised in the production to that value.

script_selector: Unsigned16

Used to define the script identifier of the script to be executed.

Implementation note: As no real scripts are implemented in CIMA / SIERRA script_selector is used to define  the state of the 16 signals TOU1..TOU16 in Tariff Application.

Definition of the bits :

ActivatePassiveCalendarTimeType: UTC

Defines the time when the object itself activates the passive calendar.

Implementation notes:

• COSEM defines the switching from passive to active by copying the values of all attributes with suffix “_passive” to the attributes with suffix “_active”. The firmware does not do the described copy process due to the large amount of EEPROM data involved. Instead, it only switches pointers from passive to active and vice versa. Because of this, the behaviour is not exactly the same but fulfills the requirement.
• From the UTC data type only year, month and day are evaluated by the firmware; all other elements (DayOfWeek, hour, minute, second, hundredths, deviation and clock_status) are ignored.
• the method activate_passive_calendar(data) which is normally used to activate the passive calendar will not be implemented. Immediate activation can be achieved by setting the value of ActivatePassiveCalendarTime to a date in the past.
• The firmware has a mechanism to internally avoid unwanted switching from passive to active. This mechanism is implemented with a flag that definines whether the attribute ActivatePassiveCalendarTime is enabled. When the flag is set and the date equals the value of active_passive_calender_time then the passive values will become the active values and the flag is cleared. The following rules apply to control the flag:
  • The flag will be cleared on writing to any attribute with suffix _passive.
  • The flag will be cleared after activating the passive values.
  • The flag will be cleared after writing a value with the "not specified" notation (0xFF) in any of the considered UTC fields of active_passive_calender_time.
  • The flag will be set after writing a valid value to active_passive_calendar_time (valid means without “not specified” in the considered UTC fields). If setting a new passive calendar, this attribute hence must be written last.

When the flag is set, the firmware compares active_passive_calender_time against the system time on the following cases:

• after a day overflow (every day at 00:00)
• after a power up
• after writing a valid value to active_passive_calendar_time.

If the current date equals or exceeds the value of active_passive_calender_time, then the passive values will become the active values (and the flag will be cleared).

After activating a passive calendar, all _passive attributes will be set to “array of 0 elements”, and the ActivatePassiveCalendarTime will return all octets as “undefined” (mostly 0xFF; see UTC definition in season_start above).

EmergencyScriptType: struct

EmergencyScript is used to define the script which is executed in case that the internal clock is not operating (e.g. due to lost of power of the clock system), or if there is an invalid entry in the activity calendar. Once the problem ceases, the scripts are executed from the corresponding day_profile. EmergencyScript contains the the logical name of the script and the script to be executed. This information is organized in a struct with two elements: Script_logical_name and Script_selector.  

script_logical_name: octetstring [6]

The script_logical_name is used as reference to select the desired script table from the Script Table class (not included in the present version of this document).

Implementation note: No real scripts are implemented in CIMA / SIERRA. Instead, the state of the 16 signals TOU1..TOU16 in Tariff Application is set using the script_selector below. The script_logical_name is equal to that of day_profiles and is always the same, set (fixed) to: 00 00 0A 00 64 FF. The firmware ignores the contents of the script_logical_name. Its value must be parameterised in the production to that value.

script_selector: Unsigned16

Used to define the script identifier of the script to be executed.

Implementation note: As no real scripts are implemented in CIMA / SIERRA script_selector is used to define  the state of the 16 signals TOU1..TOU16 in Tariff Application.

Definition of the bits :