Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000822Taste[All Projects] ASN.1 Compiler v4public2018-12-12 17:112019-05-26 15:26
Reportercavada@fbk.eu 
Assigned Togmamais 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Summary0000822:

Support present-when with expressions

Description

At the moment, asn1scc supports only present-when property with boolean fields, for optional asn fields.

----- ASN.1
T-MySeq ::= SEQUENCE
{
   field1  INTEGER(0..10),
   field2  BOOLEAN OPTIONAL,
   field3  BOOLEAN
}

---- ACN
T-MySeq []
{
   field1  [size 4, encoding pos-int],
   field2-is-present BOOLEAN [],
   field2  [present-when field2-is-present],
   field3  []
}

However, in some protocols the presence of fields depends on the values of other fields, and it is not allowed to add additional fields in the encoding.

In the previous example, this desirable ACN specification would do it:

T-MySeq []
{
   field1  [size 4, encoding pos-int],
   field2  [present-when field1 == 3],
   field3  []
}

I think that having this feature in place would provide great reward as I consider it is essential to deal with legacy encodings.
The implementation may provide several limitations, like in this list with increasing features:

  1. Support equalities for a single field appearing before the optional field (like in the example "field1 == 3")
  2. Like 0, but with general predicates (e.g. "field1 < 4")
  3. Like 1, but with predicates over multiple fields (e.g. field0 < 4 & field1 != 3)
  4. Like 2, but with fields which may appear after the optional field (e.g. "field0 < 4 & field1 != 3 | field3", where field3 appears after the optional field)

From the current encoding/decoding generated code, I think 0..2 should be relatively easy to implement, while 3 perhaps is more challenging.
I think that 0..2 may be a sensible limitation to keep.

TagsNo tags attached.
Attached Files

- Relationships
child of 0000465resolvedgmamais 

present-when expression seems not supported anymore

 

-  Notes
(0003542)
cavada@fbk.eu (reporter)
2018-12-12 17:14

Please notice that in the feature list 1..4, indices where supposed to be 0..3, but mantis changed it to 1..4.

(0003543)
maxime (administrator)
2018-12-12 19:44

Please review the comments in ticket 0000465 to get some background about the inequalities (in short: they are easy to decode, but not to encode, as the compiler would not know what values to choose)

Reagarding the equality (field1 == something) I let George answer. This is supported for CHOICE determinants, so perhaps it is possible to reuse the same logic?

(0003545)
cavada@fbk.eu (reporter)
2018-12-13 08:33

I am not sure that 0000465 applies here.

In the example (and in real cases, like for stm-05 packet of subset-058 of ERTMS/ETCS FFIS STM Application Layer specification), field1 is in ASN.1.

The idea is that IFF the user sets a given value for field1, then optional field2 must get encoded.

So if I have understood the problem in 0000465 correctly, the encoding function can check the value of field1 in ASN1 directly, so there should be no issue with inequalities. About decoding, same predicate should be applied after decoding field1 value, to know whether field2 has to de decoded or not.

(0003546)
maxime (administrator)
2018-12-13 09:08

I think this is not possible. The user is already in control of the presence field in his code (he has to set the .exist field in the data structure). If I understand correctly, what you are suggesting implies a redundant way of setting the field presence and therefore introduce a risk of inconsistency/ambiguity for the encoder.

If user sets .exist.field2 = 1 and at the same time field1 = 10 then how is the encoder going to decide what to do?
Same if the user sets .exist.field2 = 0 but sets field1 = 3, what value is the encoder going to put in field2 ?

(0003547)
cavada@fbk.eu (reporter)
2018-12-13 09:23

I see. Perhaps the encoder may check consistency, and fail with an error if .exist and the predicate are discordant?

To me your seems an implementation issue, whilst the requirement is that the user shall be able to express structures like for stm-05 package, where a specific value (level-NTC) of an enumerated field (M-LEVEL) controls the presence of another optional field (NID-NTC).

At the moment I cannot see any solution to have this packet encoded or decoded, but to write manually the encoding/decoding functions.

(0003548)
maxime (administrator)
2018-12-13 10:23

I think it is better to remain type safe. Making a runtime check and raise an errors should be avoided in that situation.

In the case 1 (field 2 is present when field1 has a fixed value) there is no reason to have field1 in ASN.1. it should be present in ACN only, since it's value is implicit depending on the presence of field2, which the user sets.
This implies allowing [present-when field1 == 10] in ACN of course, which is not yet supported. But this should be the only way to do, to avoid inconsistencies by construction. Do you agree?
If so, doesn't this cover the case you describe (a specific value or enumerated type to control the presence) ?

The other cases (inequalities) are not obvious. I originally thought of using subtyping:

D DEFINITIONS ::=
BEGIN
 T ::= SEQUENCE {
    a INTEGER (0..255),
    b BOOLEAN OPTIONAL
 } 
 T1 ::= T (WITH COMPONENTS {a (0..4 | 7..255), b PRESENT})
 T2 ::= T (WITH COMPONENTS {a (5..6),          b ABSENT})
END

Here you don't need any ACN definition and you can just decide to use T1 or T2 to guarantee the consistency and have the field present or absent (without any other determinant bit in the packet). Using the subranges with unions allow to cover the more complex cases of inequalities).

However, the decoding would be problematic : you'd need to know in advance if you receive T1 or T2 to call the correct decoding function..

So: we need to conclude on the case 1 (if ok with you, we need to update the compiler to support it) at least.
For inequalities, if that's really needed we need to give it more thought

(0003549)
cavada@fbk.eu (reporter)
2018-12-13 11:26

About having field1 only in ACN: I don't agree, as one specific value decides if field2 is present, and all the others decide that field2 is not present, so you cannot infer the value of field1 when field2 is not present (field1 is an enumerated with many literals).

I don't think there is a structural way that assure consistency. However, IMO it is much worse not being able to address a problem in legacy encodings which is not that uncommon to find.

About the use of subtyping: I also have evaluated the possibility, and made the same conclusion of unfeasability, as it is not possible to distinguish between T1 and T2 when decoding.

(0003550)
maxime (administrator)
2018-12-13 12:00

Ok, I get your point.

So we have two options:

  1. ignore the .exist field in the ACN encoder when the condition is based on another field of the ASN.1 model. The other field overrides the behaviour of the .exist field.
  2. still force the user to make .exist aligned with the other condition and have isConstraintValid return False when it's not the case

In the two options, it is implied that the user is aware of the dependency, so I would choose option 1 to simplify.

George what do you think ?

(0003642)
gmamais (developer)
2019-05-26 15:26

Issue resolved.

Now the protocol designer can put boolean expressions in the present when attributes.

Please see the the following files for more details

https://github.com/ttsiodras/asn1scc/blob/master/v4Tests/test-cases/acn/21-PresentWhenExpression/001.asn1 [^]

https://github.com/ttsiodras/asn1scc/blob/master/v4Tests/test-cases/acn/21-PresentWhenExpression/001.acn [^]


- Issue History
Date Modified Username Field Change
2018-12-12 17:11 cavada@fbk.eu New Issue
2018-12-12 17:14 cavada@fbk.eu Note Added: 0003542
2018-12-12 19:31 maxime Relationship added

child of 0000465

2018-12-12 19:44 maxime Note Added: 0003543
2018-12-12 19:44 maxime Assigned To

=> gmamais

2018-12-12 19:44 maxime Status

new => assigned

2018-12-13 08:33 cavada@fbk.eu Note Added: 0003545
2018-12-13 09:08 maxime Note Added: 0003546
2018-12-13 09:23 cavada@fbk.eu Note Added: 0003547
2018-12-13 10:23 maxime Note Added: 0003548
2018-12-13 11:26 cavada@fbk.eu Note Added: 0003549
2018-12-13 12:00 maxime Note Added: 0003550
2019-03-13 14:06 maxime Description Updated View Revisions
2019-05-26 15:26 gmamais Note Added: 0003642
2019-05-26 15:26 gmamais Status

assigned => resolved

2019-05-26 15:26 gmamais Resolution

open => fixed



Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker