61850-9-2 packets

[fhhowdy]

So, I'm trying to expand on the 61850 tests to include SV (61850-9-2) messages. I'm pretty sure that my hangup is fully understanding both the library and how the types are mapped. I've spent a lot of time reading the docs, but it's all starting to run together. The goose stuff works great, but I'm hoping to contribute to the other data types of the standards.

Starting with the existing test case that's working for goose, I tried to expand the enum to allow for the savpdu.

enum IEC61850SpecificProtocol {
    GoosePdu(IECGoosePdu),
    SavPdu(SavPdu),
    
}

This left the implementation of the sv enums:

#[derive(AsnType, Decode, Encode, Debug, PartialEq)]
#[rasn(tag(application, 0))]
struct SavPdu {
    #[rasn(tag(0))]
    no_asdu: Integer,
    #[rasn(tag(1))]
    security: Option<Any>,
    #[rasn(tag(2))]
    asdu: Vec<IECSavAsdu>,
}

#[derive(AsnType, Decode, Encode, Debug, PartialEq)]
#[rasn(tag(application, 3))]
struct IECSavAsdu {
    #[rasn(tag(0))]
    sv_id: VisibleString,
    #[rasn(tag(1))]
    datset: Option<VisibleString>,
    #[rasn(tag(2))]
    smp_cnt: OctetString,
    #[rasn(tag(3))]
    conf_rev: OctetString,
    #[rasn(tag(4))]
    refr_tm: UtcTime,
    #[rasn(tag(5))]
    smp_sync: OctetString,
    #[rasn(tag(6))]
    smp_rate: OctetString,
    #[rasn(tag(7))]
    sample: OctetString,
    #[rasn(tag(8))]
    smp_mode: OctetString,
    #[rasn(tag(9))]
    t: Option<UtcTime>,
}

But when I run the decoder:

let data = rasn::ber::decode(&data[idx..]).expect("Expected SV"); 

I get the following output:

thread 'main' panicked at 'Expected SV: NoValidChoice { name: "IEC61850SpecificProtocol" }'

Calling the function on a goose message works perfectly and I can access all of the data, but the sampled values do not work.

There are several places where I could see potential errors. The first is finding out what "choice" the decoder is looking for. I'm new to Rust (I've literally been using it for about 2 weeks), and I'm not sure how to debug what the library is looking for.

Another is regarding the way I mapped the asdu. In the standard, there are several specifically sized OctetStrings (size(1), size(2), size(4). Does this need to be specified some way in the enum, or do I leave it as a generic OctetString.

The last is regarding the "application" tag. I'm not sure what the number does, but I did have to make them unique for the code to compile. Goose was 1, so I used 0 and 3 in this example (2 is being used in an MMS example I'm also working on). I don't anticipate that the value really matters here, but if it does, then I've probably got it wrong.

Thanks in advance for any pointers.

[XAMPPRocky]

Thank you for your question! I need a bit more information before I can say for certain what is wrong. I'd need to see the original ASN.1 schema to be able to check against your implementation.

There are several places where I could see potential errors. The first is finding out what "choice" the decoder is looking for. I'm new to Rust (I've literally been using it for about 2 weeks), and I'm not sure how to debug what the library is looking for.

The choice is IEC61850SpecificProtocol, when it gives that error message, it's saying it can't find any valid variant for IEC61850SpecificProtocol.

Another is regarding the way I mapped the asdu. In the standard, there are several specifically sized OctetStrings (size(1), size(2), size(4). Does this need to be specified some way in the enum, or do I leave it as a generic OctetString.

If you're encoding to DER, CER, or BER (which are the only supported formats currently), it shouldn't matter because the format always has a tag, length, value, even when the string has a fixed size. (When support for PER is added, this will change, because it needs the constraints to properly decode and encode the message, but this is not available in the library yet).

The last is regarding the "application" tag. I'm not sure what the number does, but I did have to make them unique for the code to compile. Goose was 1, so I used 0 and 3 in this example (2 is being used in an MMS example I'm also working on). I don't anticipate that the value really matters here, but if it does, then I've probably got it wrong.

Yes, this is required to match what is provided in the ASN.1 schema in order to be able to encode and decode the message, it does matter, so that's probably at least one place where your code is failing.

[fhhowdy]

I'm attaching the ASN.1 diagram for the 9-2 packets. I did manage to get a debugger working and it is failing with an incorrect application id, which I expect may be the initial failure. But I imagine that there are other issues as well. I've got to be close, though.

Also, I'm guessing that the choice is specific to this protocol, so I've split out the choice to be a separate item with just the SavPdu as an option. That hasn't worked, either, but comparing the ASN diagrams, this feels like the more proper thing to do.

[fhhowdy]

I set the application to 0 as per the ASN guidance, and the ber routine appears to go fairly deep into the packet before dying. The error is basically the same, but it's not related to the initial choice for the savpdu. I think it might be with my implementation of the vector of asdu's. Is it legal for me to nest custom types the way I did, or should I have done something different?

[XAMPPRocky]

@fhhowdy The security field needs an explicit tag rather than an implicit tag, changing it to #[rasn(tag(explicit(1)))] should fix it.

[fhhowdy]

Thank you! I don't know that I would have ever caught that. Is there documentation that I can read up on to better understand what's going on with the implicit/explicit settings? Your suggestion worked, and the code is working. I'll need to play around with it a little, but then I'll try to do a pull request to add an example similar to what you've done with the goose message.

[XAMPPRocky]

This documentation is the probably the best without looking at the actual X.680 and X.690 standards. I hope to improve the rasn documentation to be a good source for this information. https://www.oss.com/asn1/resources/asn1-made-simple/asn1-quick-reference/asn1-tags.html