As some background, see the following article:
This article discusses how to add some information to the J2735 specification.
This specific blog post discusses how to add information for a new region to the J2735 specification, generate code for it using ASN1C, and then reference the new material in your own code. In this example we will add a GenericLane definition for a new region named Mars. That's Mars as in the planet, not the town in western PA.
To start, the J2735 ASN.1 specification defines a type called a RegionId as follows:
RegionId ::= INTEGER (0..255) noRegion RegionId ::= 0 -- Use default supplied stubs addGrpA RegionId ::= 1 -- USA addGrpB RegionId ::= 2 -- Japan addGrpC RegionId ::= 3 -- EU -- NOTE: new registered regional IDs will be added here -- The values 128 and above are for local region use
This definition is in the DSRC module in the ASN.1 file. If you read the background material (you did, didn't you?), you know that the DSRC module is not to be modified by users of the J2735 specification.
But the background material also indicates that there is a module named REGION in the ASN.1 file that can be modified by developers. So let's make the first line of this module look like this:
marsRegion RegionId ::= 222
The background material says to let SAE know what number you've chosen so it can be tracked. Since there is no intention that I know of to define intelligent traffic systems on the planet Mars, this number 222 isn't actually being reported to SAE and remains available for anyone else to use.
Now a few lines down let's modify the Reg-GenericLane definition so it looks like this:
Reg-GenericLane DSRC.REG-EXT-ID-AND-TYPE ::= {
{ Mars.GenericLane-mars IDENTIFIED BY marsRegion },
... }
Then at the end of the ASN.1 file let's add a module named Mars that looks like this:
-- ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-
--
-- Begin module: Mars
--
-- ^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-
Mars DEFINITIONS AUTOMATIC TAGS::= BEGIN
GenericLane-mars ::= SEQUENCE {
laneType LaneType,
distanceFromViking1 INTEGER, -- Since this is a distance, it could be constrained to be positive
hue RedHue,
...
}
LaneType ::= ENUMERATED {
martian-lane (1),
rover-lane (2),
...
}
RedHue ::= ENUMERATED {
light-red (1),
deep-red (2),
...
}
END
That's it as far as the ASN.1 changes are concerned. Now let's generate some C++ code using ASN1C with a command like this, assuming our changed ASN.1 definitions are in a file named J2735Mars.asn:
asn1c j2735Mars.asn -uper -cpp -table-unions -genwriter -genreader -genprint -pdu GenericLane -gentest
Let's look at what those qualifiers do:
- -uper: Specifies that we're using unaligned PER (Packed Encoding Rules).
- -table-unions: Specifies that the code generation should take into account inter-dependencies within the ASN.1 definitions. These inter-dependencies are known as table constraints.
- -genwriter: Specifies that we want to generate a writer program (writer.cpp) that will encode an instance of our message.
- -genreader: Specifies that we want to generate a reader program (reader.cpp) that will decode an instance of our message.
- -genprint: Specifies that we want to generate methods to print the contents of the message.
- -pdu GenericLane: Specifies that our writer and reader programs are to work with an instance of GenericLane (as opposed to any of the other definitions in the ASN.1 file).
- -gentest: Specifies that the writer is to generate random test data to populate our GenericLane instance.
You can also add -genmake to generate a makefile that will build the writer and reader binaries.
If you generate the code and then build it, you will have a writer binary that will encode the message into a file named message.dat, and you will have a reader binary that will decode the message that's in the message.dat file. For my specific situation my message looked like this:
GenericLane {
laneID = 252
name = 'AMXrH7pmSZHULHTJ:Us_gUAqMrI'
ingressApproach = 1
egressApproach = 3
laneAttributes {
directionalUse = { 2, 01xxxxxx }
sharedWith = { 10, 0x72 01xxxxxx }
laneType {
sidewalk = { 16, 0x48 0x61 }
}
regional {
regionId = 254
regExtValue = 0x04083677ccd172888708
}
}
maneuvers = { 12, 0x5E 0100xxxx }
nodeList {
computed {
referenceLaneId = 181
offsetXaxis {
large = -9096
}
offsetYaxis {
small = 253
}
rotateXY = 18514
scaleXaxis = 1124
scaleYaxis = -1034
regional[0] {
regionId = 119
regExtValue = 0x040831403e5e9dfbcb99
}
}
}
connectsTo[0] {
connectingLane {
lane = 189
maneuver = { 12, 0x53 0100xxxx }
}
remoteIntersection {
region = 16975
id = 25828
}
signalGroup = 245
userClass = 0
connectionID = 70
}
overlays[0] = 9
regional[0] {
regionId = 222
regExtValue {
GenericLane-mars {
laneType = martian-lane
distanceFromViking1 = 3814
hue = light-red
}
}
}
}
Keep in mind that this data is randomly generated test data, and it will be different with each code generation. Note the "regional" section at the end, which is where we added our information about lanes on Mars. The test data generator chose our Mars definition, probably because it's the only one there. But you can see values for the fields we added for traffic lanes on Mars.
The writer.cpp file calls the genTestInstance() method of the GenericLanePDU object, which is an instance of the class ASN1C_GenericLane. The code for this genTestInstance() method is in the generated file DSRCTest.cpp. The end of the method is where the new items are given values.