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
|
# High level binding
CAN binder, based upon ViWi definition.
This binding is intended to act between the low-level binding and clients. It collects resources as defined in a json configuration file, and
implements subscribe/unsubscribe/get verbs for the clients.
# build
```bash
git submodule init
git submodule update
mkdir build
cd build
cmake ..
make
```
> ! WARNING don't forget to initialize submodule needed to build the project.
# launching
natively under linux you can launch afb-daemon with the low-level and high-level bindings with a command like:
```bash
afb-daemon --rootdir=<path_to_low_binding>/CAN-binder/build/package --ldpaths=<path_to_low_binding>/CAN-binder/build/package/lib:<path_to_high_binding>/build/high-can-binding --port=1234 --tracereq=common --token=1 --verbose --verbose --verbose
```
#json configuration file
json configuration file (high.json) must be placed in the directory where you will launch afb-dameon
The json configuration file consists in 2 sections:
## definitions section
This section describes each resources defined in the high-level binding. Each resource is composed with different properties having a name, a type and a description.
Type can be boolean, double, string, or int. Properties "id", "uri" and "name" are compulsory.
For instance:
```json
{
"name": "/car/demoboard/",
"properties": {
"id": {
"type": "string",
"description": "identifier"
},
"uri": {
"type": "string",
"description": "object uri"
},
"name": {
"type": "string",
"description": "name"
},
"unit": {
"type": "string",
"description": "units"
},
"speed": {
"type": "double",
"description": "vehicle centerpoint speed as shown by the instrument cluster"
},
"rpm": {
"type": "double",
"description": "engine rotations per minute"
},
"level": {
"type": "double",
"description": "level of tankage"
},
"load": {
"type": "double",
"description": "engine load"
}
}
}
```
## resources section
This section defines which values should be assigned to resource's properties as defined in the definitions section.
The link to the definitions section is made through the name of the resource.
Some values are static, some are linked to low-level requests.
In case a value is linked to a low-level request, the value will start with "${" and end with "}". In that case the value will consist in the name of the low-level signal, followed
with the frequency of the signal in ms. -1 in the frequency means that high level binding should subscribe to low level binding for all changes, without specifying a frequency.
For instance:
```json
{
"name": "/car/demoboard/",
"values": [{
"name": "vehicleSpeed",
"unit": "km/h",
"speed": "${diagnostic_messages.vehicle.speed,1000}"
}, {
"name": "engineSpeed",
"unit": "rpm",
"rpm": "${diagnostic_messages.engine.speed,1000}"
}, {
"name": "fuelLevel",
"unit": "litre",
"level": "${diagnostic_messages.fuel.level,1000}"
}, {
"name": "engineLoad",
"unit": "Nm",
"load": "${diagnostic_messages.engine.load,1000}"
}]
}
```
# Running and testing
You can use afb-client-demo to test high level binding.
For instance, once daemon has been launched with the 2 bindings:
```bash
afb-client-demo ws://localhost:1234/api?token=1
```
You can then use commands such as:
```bash
high-can subscribe {"name":"/car/doors/","interval":10000}
high-can unsubscribe {"name":"/car/doors/","interval":10000}
high-can get {"name":"/car/demoboard/"}
high-can get {"name":"/car/demoboard/","fields":["fuelLevel","engineLoad"]}
```
You can also inject some data in CAN bus using canplayer (example of data can be find in low-level binding example directory)
```bash
canplayer -I highwaycomplete
```
|
