Why does Class 22 Single Action Schedule (0.0.15.0.1.255) return read-write-denied on multi-element execution_time arrays?

[carlos_mendez]

[!WARNING]
Technical Redaction & Safe Harbor Notice:
All communication captures, system titles, and cryptographic parameters in this thread have been sanitized and neutralized. Real utility meter identifiers, production encryption keys (GUEK/GAK/MK), SIM IMSIs, and proprietary network envelopes have been substituted with standard IEC 62056 synthetic test vectors. Do not post unredacted production captures or live cryptographic keys.

We are currently integrating automated daily load-shedding and reconnect schedules on three-phase polyphase smart meters over IEC 62056-47 TCP/IP (port 4059). According to our requirements, the meter must trip its internal breaker (Class 70, OBIS 0.0.96.3.10.255) at 06:20:00 and again at 06:25:00.

We targeted Disconnect Control Single Action Schedule (Class 22, OBIS 0.0.15.0.1.255), writing two time entries into Attribute 4 (execution_time). Since the DLMS UA Blue Book defines execution_time as array of execution_time_type, our HES generated the following sanitized Set-Request-Normal APDU:

00 01 00 01 00 01 00 24 C1 01 C1 00 16 00 00 0F 00 01 FF 04 00 01 02 02 02 09 04 06 14 00 00 09 05 FF FF FF FF FF 02 02 09 04 06 19 00 00 09 05 FF FF FF FF FF

Dissecting the payload:

• C1 01 C1: Set-Request-Normal, Invoke-ID 1
• 00 16: Class ID 22 (Single Action Schedule)
• 00 00 0F 00 01 FF: OBIS 0.0.15.0.1.255
• 04 00: Attribute 4 (execution_time), no selective access
• 01 02: Array with length 2
• Element 1 (02 02 Time 06:20:00.00 (09 04 06 14 00 00), Date wildcard (09 05 FF FF FF FF FF)
• Element 2 (02 02 Time 06:25:00.00 (09 04 06 19 00 00), Date wildcard (09 05 FF FF FF FF FF)

However, the meter persistently rejects this payload with Data-Access-Result: read-write-denied:

00 01 00 01 00 01 00 04 C5 01 C1 03

What is baffling is that if we send a single element (01 01 02 02 09 04 06 14 00 00 09 05 FF FF FF FF FF), the meter returns Data-Access-Result: success (0x00). If the data type is structurally an Array, why does setting two valid execution time structures fail with read-write-denied rather than type-unmatched?

[elena_rostova]

Carlos, your assumption that an A-XDR array type definition guarantees variable-length dynamic array support in embedded meter firmware is a classic protocol misunderstanding.

Look closely at the internal relationship between Attribute 3 (type) and Attribute 4 (execution_time) defined in DLMS UA Blue Book (17th Ed.) Section 4.5.4. Attribute 3 dictates how the meter runtime evaluates the execution schedule:

Type 1: Single execution time (size = 1)
Type 2: Array of n execution times (all elements must share the identical time)
Type 3: Array of n execution times (identical time with wildcards)
Type 4: Array of n execution times (different times allowed, exact dates)
Type 5: Array of n execution times (different times and wildcards allowed)

When you read Attribute 3 of 0.0.15.0.1.255, the meter almost certainly returns 16 01 (enum = 1, Type 1). In embedded firmware running on low-power 32-bit MCUs (such as ARM Cortex-M0+/M3), dynamic heap allocation (malloc) is strictly forbidden for metrological safety. The schedule storage is allocated as a fixed C struct in NVRAM/EEPROM:

typedef struct {
    uint8_t hour, min, sec, hundredths;
    uint8_t year_h, year_l, month, day, day_of_week;
} cosem_single_action_time_t;

// Static buffer sized exactly for Type 1
cosem_single_action_time_t g_disconnect_schedule_slot;

When your SET request arrives with 01 02 (Array Qty = 2), the firmware's A-XDR validator checks both the schema and the active schedule type. Because type == 1, passing an array length greater than 1 violates the semantic constraints of the object. Per DLMS Green Book 10th Ed Section 9.3.4 (Table 46: data-access-result), when a value is outside the device's operational range or semantic capability, returning read-write-denied (0x03) or temporary-failure is the standard conformant behavior.

Moreover, if you attempt to SET Attribute 3 to 16 05 (Type 5), you will also receive 0x03 because the firmware developer sealed Attribute 3 as read-only to prevent runtime heap exhaustion.

[sarah_jenkins]

Elena's firmware analysis is spot on. Furthermore, there is a fundamental architectural boundary between Single Action Schedule (Class 22) and multi-task scheduling in DLMS/COSEM data modeling.

Per DLMS Blue Book Section 4.5.4 and IEC 62056-62 Clause 4.5.4, Class 22 has a single executed_script field in Attribute 2:

executed_script ::= structure {
    script_logical_name : octet-string,
    script_selector     : long-unsigned
}

This establishes a strict 1-to-N binding: one script action bound to $N$ execution timestamps. Class 22 has no mechanism to map 06:20 $\rightarrow$ Script 1 (Trip) and 06:25 $\rightarrow$ Script 2 (Close). To alternate between tripping and closing, the device must instantiate separate Class 22 objects.

Notice the standard OBIS allocations in Blue Book Section 4.5.4 / Table 42:

• 0.0.15.0.1.255: Disconnect control Single action schedule (dedicated to tripping)
• 0.0.15.0.3.255: Output control Single action schedule (borrowed by vendors for reconnecting)
• 0-0:10.0.106*255: Disconnect control Script table (Class 9)

If you genuinely require an arbitrary list of heterogeneous scheduled tasks (e.g., 08:00 Disconnect, 09:30 Reconnect, 12:00 Profile Capture), the proper COSEM object model is Class 10 (Schedule) per Blue Book Section 4.5.3. In Class 10, each entry in Attribute 2 (schedule_table_entry) contains its own script_logical_name, script_selector, switch_time, and validity day masks.

However, because Class 10 has a heavy RAM footprint, most smart meters omit Class 10 and instead provide two fixed Class 22 slots (.1.255 for Trip, .3.255 for Close), both locked to Type 1 single-shot execution.

[marcus_vance]

This completely clarifies the HES integration strategy. Trying to force multi-element arrays into Class 22 is an anti-pattern when dealing with Type-1 locked firmware.

Rather than guessing array capabilities, a robust Head-End System must inspect the Association LN (Class 15, OBIS 0.0.40.0.0.255) object_list during commissioning. If 0.0.15.0.1.255 and 0.0.15.0.3.255 are present with Attribute 3 returning Type 1, the HES scheduler should manage two distinct single-shot requests.

Here is the verified working sequence to program a daily 06:20:00 disconnect on 0.0.15.0.1.255:

00 01 00 01 00 01 00 1B C1 01 C1 00 16 00 00 0F 00 01 FF 04 00 01 01 02 02 09 04 06 14 00 00 09 05 FF FF FF FF FF

Meter response:

00 01 00 01 00 01 00 04 C5 01 C1 00

And here is the verified working sequence to program the 06:25:00 reconnect on 0.0.15.0.3.255:

00 01 00 01 00 01 00 1B C1 01 C2 00 16 00 00 0F 00 03 FF 04 00 01 01 02 02 09 04 06 19 00 00 09 05 FF FF FF FF FF

Meter response:

00 01 00 01 00 01 00 04 C5 01 C2 00

Here is the production-tested Python snippet using Gurux.DLMS to handle this fallback gracefully:

from gurux_dlms.objects import GXDLMSSingleActionSchedule
from gurux_dlms.objects.enums import SingleActionScheduleType
from gurux_dlms import GXDateTime

def configure_single_action_schedule(client, obis_code, exec_hour, exec_min):
    schedule = GXDLMSSingleActionSchedule(obis_code)
    client.read(schedule, 3) # Read Attribute 3: type
    
    # Construct date-time structure with wildcards for daily recurring execution
    target_time = GXDateTime(-1, -1, -1, exec_hour, exec_min, 0, 0)
    
    if schedule.type == SingleActionScheduleType.SINGLE_ACTION_SCHEDULE_TYPE1:
        # Firmware strictly enforces Qty = 1
        schedule.executionTime = [target_time]
    else:
        # Extended multi-time support if enabled on advanced meters
        schedule.executionTime.append(target_time)
        
    # Generate and transmit SET-Request APDU for Attribute 4
    return client.write(schedule, 4)

By splitting the schedule across the dedicated .1.255 and .3.255 instances and respecting the Type 1 constraint, all SET requests return Data-Access-Result: success (0x00) without risking breaker desynchronization.