-
-
Notifications
You must be signed in to change notification settings - Fork 136
/
dbcc.xsd
141 lines (135 loc) · 5.59 KB
/
dbcc.xsd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<!-- This XSD file describe the output from the DBCC program, a program
that turns DBC files into something more useful (either C code or XML ),
see https://github.com/howerj/dbcc for more information.
There is more information that needs to be included in this files, as a DBC
file also contains information about which nodes receive and send signals, and
there is extra type information for signals (like specific values meaning special
things) which currently are not processed by DBCC. Multiplexed signals and
information about remote frames is also not stored, as it is not yet extracted.
This XSD cannot describe CAN FD messages and signals. -->
<!-- The CAN database is comprised of messages which each node (or ECU)
connected to the bus can send or receive -->
<xs:element name="candb">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" ref="message"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- A can message is a package of data that is broadcast to each ECU on the
bus, it has an ID and a package length, with zero to eight bytes of
data -->
<xs:element name="message">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="id" type="can-id"/>
<!-- 11 or 29 bit CAN ID -->
<xs:element name="dlc" type="dlc"/>
<xs:element maxOccurs="1" minOccurs="0" name="extended" type="intBool"/>
<xs:element minOccurs="0" maxOccurs="unbounded" ref="signal"/>
<xs:element maxOccurs="1" minOccurs="0" ref="multiplexor-group"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- A signal is a member of a message, it describes how to turn
a message into a type (such as a float, an integer, ...) by
specifying where in the message and how many bits the value it.
Instead of doing the rational thing and only choosing and standardizing
on one endianess (does not matter which one, just pick *one*) messages
can contain signals of differing endianess -->
<xs:element name="signal">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="startbit" type="startbit"/>
<xs:element name="bitlength" type="bitlength"/>
<xs:element name="endianess" type="endianess"/>
<xs:element name="scaling" type="xs:float"/>
<xs:element name="offset" type="xs:float"/>
<xs:element name="minimum" type="xs:float"/>
<xs:element name="maximum" type="xs:float"/>
<xs:element name="signed" type="xs:boolean"/>
<xs:element name="floating" type="xs:unsignedInt"/>
<xs:element name="units" type="xs:string"/>
<!-- an optional multiplexor, of which there can only be one per
message -->
<xs:element minOccurs="0" maxOccurs="1" name="multiplexed-on" type="xs:unsignedInt"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- a multiplexor group consists of a multiplexor and a series of messages,
which signal gets decoded depends on the value of the multiplexor -->
<xs:element name="multiplexor-group">
<xs:complexType>
<xs:sequence>
<xs:element ref="multiplexor"/>
<xs:element minOccurs="0" maxOccurs="unbounded" ref="multiplexed"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- a multiplexor is just an ordinary signal, although it really should be
unsigned... -->
<xs:element name="multiplexor">
<xs:complexType>
<xs:sequence>
<xs:element ref="signal"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- a multiplexed signal consists of a value that the multiplexor should be
when the signal is to be decoded and a descriptor of the signal -->
<xs:element name="multiplexed">
<xs:complexType>
<xs:sequence>
<xs:element name="multiplexed-on" type="xs:unsignedInt"/>
<xs:element ref="signal"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- Only two valid byte orders, "motorola" (Big Endian) and "intel" (Little Endian) -->
<xs:simpleType name="endianess">
<xs:restriction base="xs:string">
<xs:enumeration value="motorola"/>
<xs:enumeration value="intel"/>
</xs:restriction>
</xs:simpleType>
<!-- 2^29-1 for 29 bit CAN IDs, 2047 for 11-bit can IDS -->
<xs:simpleType name="can-id">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="3221225472"/> <!-- Maximum ID should be '536870911', some DBCs do not abide by this -->
</xs:restriction>
</xs:simpleType>
<!-- DLC 0-8 are valid values -->
<xs:simpleType name="dlc">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="8"/>
</xs:restriction>
</xs:simpleType>
<!-- Bit lengths of zero do not make sense, the maximum bit length is
the maximum length in a CAN package -->
<xs:simpleType name="bitlength">
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="64"/>
</xs:restriction>
</xs:simpleType>
<!-- Offset into the CAN package data, limited by maximum length of a CAN
package -->
<xs:simpleType name="startbit">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="64"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="intBool">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>