Dual Single Action Schedule (Class 22) vs Unified Schedule Table (Class 10): Practical Workaround or OBIS Misuse?

[sarah_jenkins]

[!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.

In standard DLMS/COSEM data modeling, managing heterogeneous multi-point time-based operations (such as alternating trip and close schedules, tariff changes, and billing snapshots) is standardized under Class 10 (Schedule) per DLMS UA Blue Book (17th Ed.) Section 4.5.3.

However, during our cross-vendor meter benchmarking, we probed for the standard Schedule object (Class 10, OBIS 0-0:12.0.0*255) across several polyphase meter families. Probing Attribute 1 (logical_name) with standard Get-Request-Normal:

00 01 00 01 00 01 00 0D C0 01 C3 00 0A 00 00 0C 00 00 FF 01 00

The meters consistently return Get-Response-With-Service-Error with error code 0xFA (250 = other-reason

00 01 00 01 00 01 00 05 C4 01 C3 01 FA

Instead of supporting Class 10, meter vendors commonly instantiate two separate Class 22 (Single Action Schedule) objects:

• 0.0.15.0.1.255: Pre-configured for Disconnect
• 0.0.15.0.3.255: Pre-configured for Reconnect

Per Blue Book Table 42, 0.0.15.0.3.255 is officially designated as Output control Single action schedule (intended for auxiliary relay or pulse terminals), while 0.0.15.0.1.255 is Disconnect control Single action schedule.

Is appropriating .3.255 as a dedicated reconnect scheduler a pragmatic industry consensus, or does it represent an unacceptable violation of OBIS semantics that breaks standard HES auto-discovery?

[david_miller]

Sarah, from a protocol conformance and multi-vendor interoperability standpoint, appropriating 0.0.15.0.3.255 as an ad-hoc breaker reconnect scheduler is a dangerous anti-pattern.

Look closely at IEC 62056-61 (OBIS Identification System) Section 6.2 and DLMS UA Blue Book (17th Ed.) Table 42. The OBIS hierarchy allocates 0.0.15.0.x.255 codes with distinct physical and logical semantics:

• 0.0.15.0.0.255: End of billing period schedule
• 0.0.15.0.1.255: Disconnect control schedule (Class 70 breaker)
• 0.0.15.0.2.255: Image activation schedule (Class 18 OTA)
• 0.0.15.0.3.255: Output control schedule (Class 71 / Class 1 auxiliary outputs)

If a vendor repurposes .3.255 to execute Disconnect Control Script 2 (Reconnect) without explicit specification, an interoperable utility HES that strictly relies on standard OBIS semantics will interpret .3.255 as controlling physical auxiliary relay contacts (such as ripple control or tariff indicator outputs).

If the HES writes a schedule into .3.255 expecting to control external load contactors, but the meter firmware internally trips or closes the main supply breaker, this can cause unintended grid switching. Standards exist precisely to eliminate undocumented proprietary mappings.

[elena_rostova]

David, while your concerns regarding strict OBIS semantics are valid in theory, from an embedded microcontroller firmware perspective, omitting Class 10 in favor of dual Class 22 instances is an essential engineering optimization.

Let's analyze the firmware execution overhead. In Class 10 (Schedule) per Blue Book Section 4.5.3, Attribute 2 is an array of complex schedule_table_entry structures containing 10 fields each:

typedef struct {
    uint16_t logical_index;
    bool enabled;
    uint8_t script_ln[6];
    uint16_t script_selector;
    cosem_time_t switch_time;
    uint16_t validity_window;
    uint8_t exec_weekdays_mask;
    uint8_t exec_specdays_mask;
    cosem_date_t begin_date;
    cosem_date_t end_date;
} schedule_table_entry_t;

Implementing Class 10 requires:

1. A dynamic sorting and scheduling engine running on every 1-second RTC tick interrupt;
2. Complex calendar matching against Daylight Saving Time (Class and Special Days (Class 11);
3. Up to 2KB to 4KB of dedicated battery-backed NVRAM for multi-entry tables.

On the other hand, Class 22 is a lean 16-byte comparator. By providing two static Class 22 instances (.1.255 and .3.255), the meter firmware achieves 99% of utility requirements (one scheduled load shed and one scheduled restoration per day) with zero dynamic memory risk.

[carlos_mendez]

This debate highlights the classic tension between pure data modeling standards and real-world embedded deployment constraints. In the field, we cannot assume how a meter binds .3.255 without dynamic verification.

The reliable engineering solution for any Head-End System is to implement Attribute 2 Binding Verification during device discovery.

Instead of assuming .3.255 controls auxiliary outputs or breaker reconnects, the HES must read Attribute 2 (executed_script) of both Class 22 objects. Here is the verified readback from 0.0.15.0.3.255:

00 01 00 01 00 01 00 13 C4 01 C1 00 02 02 09 06 00 00 0A 00 6A FF 12 00 02

Dissecting the script reference:

• 09 06 00 00 0A 00 6A FF: Target script LN 0-0:10.0.106*255 (Disconnect Control Script Table)
• 12 00 02: Script selector 2 (Remote Reconnect)

And here is the production Python snippet demonstrating how to dynamically determine whether .3.255 is safely wired to reconnect or auxiliary output:

from gurux_dlms.objects import GXDLMSSingleActionSchedule

def resolve_reconnect_schedule_obis(client):
    schedule_reconnect = GXDLMSSingleActionSchedule("0.0.15.0.3.255")
    
    # Read Attribute 2: executed_script
    client.read(schedule_reconnect, 2)
    
    target_ln = schedule_reconnect.executedScriptLogicalName
    script_selector = schedule_reconnect.executedScriptSelector
    
    # Verify if vendor mapped .3.255 to Disconnect Control Script 2 (Reconnect)
    if target_ln.to_bytes() == b'\x00\x00\x0A\x00\x6A\xFF' and script_selector == 2:
        return "0.0.15.0.3.255" # Confirmed safe reconnect slot
    
    raise NotImplementedError("Meter does not provide a dedicated Disconnect Control reconnect schedule.")

By verifying the executed script pointer at runtime, the HES guarantees safe automated load management regardless of whether the meter implements unified Class 10 or split Class 22 slots.