Improve Toyota examples.
[apps/agl-service-can-low-level.git] / README.md
1 # Low level CAN signaling binder
2
3 ## Abstract
4
5 Low level CAN bus binder, based upon OpenXC vi-firmware project.
6
7 Purpose of this project is to offer a low level binding to an AGL platform, idea remains the same than OpenXC project.
8
9 It's meant to generate from a JSON file describing CAN messages and diagnostic message (OBD2 for now), a cpp file to integrate with the project.
10
11 Once generated binding is built with it and result will be a widget file to install on an AGL target system.
12
13 ![OpenXC_to_AGL][OpenXC_to_AGL]
14
15 ## AGL CAN binding architecture proposal
16
17 Bring CAN management into the AGL project is more than allowing decode and print CAN messages, lot of tools can do that (Wireshark, CAN-utils, ...).
18
19 The goal is to provide a common API and abstraction to the CAN bus then you can bring some more high level functionnalities to the system.
20
21 CAN binding will be separated in two parts:
22
23 ![CAN_mapping][CAN_mapping]
24
25 - High level: Binding from which others applications will connect to.
26 It will provides valuable access to the CAN bus by aggregate signals or providing new signals from several originals. For example, a signal exposing whether or not a door is open, no matter which one it is. Also, we can imagine an application which supervise if there is no one in the car but moving (1m, 2m ?) to alert the owner of an unexpected behavior. The high level binding will sends a single event representing that behavior to the application which in turn will send a phone message to.
27
28 - Low level: Decode messages that transit and send event through **Application Framework** to the subscribers with human readable message. It provides some basic access to the bus + some basic mathematical, statistical features (last_values, min, max, timestamps, averaging) as well as basic filter to get discerning signal only (This part are not implemented yet in the low level).
29
30
31 ![Binding_architecture][CAN_bindings_communication]
32
33 Last be not least, the low level binding can be shipped as binary only using OpenXC inspired [generator][generator].
34
35 # Prerequirements
36
37 - An AGL system installed with a Chinook version.
38
39 - Make sure you already have set up the AGL SDK before using the following [guide][SDK_instructions]. 
40
41 To get the correct SDK version installed, you **must** prepare your environment with the **chinook-next** version. To do so, run the following command in your docker image:
42
43 ```bash
44 $ prepare_meta -f chinook-next -o /xdt -l /home/devel/mirror -p /home/devel/share/proprietary-renesas-rcar/ -t porter -e wipeconfig -e rm_work
45 ```
46
47 - Check that you have updated git submodules, executing the following commands from the repository:
48
49 ```bash
50 $ git submodule init
51 $ git submodule update
52 ```
53
54 - An [USB CAN adapter][USB_CAN] connected to OBD2 connector through the [right cable][OBD2_cable].
55
56 - Make sure you have installed the AGL generator else you aren't able to generate custom low-level CAN binding. Generator can be found [here][generator] with the attached instruction to install and run it. It will produce a *configuration-generated.cpp* file to paste in the source, *src/*, directory.
57
58 # Getting started
59
60 ## Compile and install the binding
61
62 With an AGL SDK environment correctly set, I encourage you to set the TARGET variable in the root CMakeLists.txt file if you have an AGL target already running in your network.
63
64 Then you can directly build and install the binding and source directory on your target system.
65
66 Execute commands to get your binding compile :
67
68 ```bash
69 $ mkdir build
70 $ cd build
71 $ cmake ..
72 $ make
73 ```
74
75 And if you have set TARGET variable, you can install it on your AGL system :
76
77 ```bash
78 $ make install
79 [ 16%] Built target bitfield
80 [ 27%] Built target isotp
81 [ 40%] Built target openxc
82 [ 48%] Built target uds
83 [ 97%] Built target low-can-binding
84 [100%] Built target widget
85 Install the project...
86 -- Install configuration: ""
87 true
88 { "added": "low-can-binding@0.1" }
89 ```
90
91 It's possible that you'll see the following message :
92
93 ```bash
94 Error org.freedesktop.DBus.Error.Failed: "system error"
95 ```
96 It's because installation remove the binding before installing it.
97
98 If it is the first time that you make the installation then you'll have this message in place of ***true***.
99
100 To install it manually, you need to copy the *low-can-binding.wgt* file on your target, then from it execute the following commands :
101
102 On your host, to copy over the network :
103 ```bash
104 $ scp low-can-binding.wgt root@<target_IP>:~
105 ```
106
107 On the target, assuming ***wgt*** file is in the root home directory :
108
109 ```bash
110 ~# afm-util install low-can-binding.wgt
111 { "added": "low-can-binding@0.1" } 
112 ```
113 ## Install AFB Websocket CLI client to test the binding.
114
115 You can test it using afb-client-demo CLI tool provided by the RPM package *libafbwsc-dev*.
116
117 You can find this package in your build environment, using docker SDK recommended setup the file is */xdt/build/tmp/deploy/rpm/<your-target-arch>/*. 
118
119 Using Renesas RCar Gen2, Porter board, you have to copy the file like this if your board is connected to your network and you know its IP address:
120
121 ```bash
122 $ scp /xdt/build/tmp/deploy/rpm/cortex15hf_neon/libafbwsc-dev-1.0-r0.cortexa15hf_neon.rpm root@<target_IP>:~
123 ```
124
125 Else, you have to copy into the SDcard with the AGL image installed on it.
126
127 From the docker image copy RPM to the shared directory between docker image and your host:
128
129 ```bash
130 $ cp /xdt/build/tmp/deploy/rpm/cortex15hf_neon/libafbwsc-dev-1.0-r0.cortexa15hf_neon.rpm ~/share
131 ```
132
133 Then plugin you SDcard in your Linux host (Windows can't read ext4 filesystem AGL runs on) and copy RPM file on it.
134
135 From you host, identify SDcard block device node here it is **sdc** with the correct capacity automounted by the desktop manager:
136
137 ```bash
138 $ lsblk
139 loop1                                                                                     7:1    0     2G  0 loop 
140 └─docker-253:0-3146365-pool                                                             253:3    0   100G  0 dm   
141   └─docker-253:0-3146365-e9f80849a2681e18549d3a4238cbf031e44052e36cd88a0abf041804b799b61c
142     253:4    0    10G  0 dm   /var/lib/docker/devicemapper/mnt/e9f80849a2681e18549d3a4238cbf031e44052e36cd88a0abf041804b799b61c
143 sdb                                                                                       8:16   0 238.5G  0 disk 
144 ├─sdb2                                                                                    8:18   0   238G  0 part 
145 │ └─Shamash-agl                                                                         253:1    0   238G  0 lvm  /home/claneys/Workspace/agl-docker
146 └─sdb1                                                                                    8:17   0   500M  0 part /boot
147 sr0                                                                                      11:0    1  1024M  0 rom  
148 loop0                                                                                     7:0    0   100G  0 loop 
149 └─docker-253:0-3146365-pool                                                             253:3    0   100G  0 dm   
150   └─docker-253:0-3146365-e9f80849a2681e18549d3a4238cbf031e44052e36cd88a0abf041804b799b61c
151     253:4    0    10G  0 dm   /var/lib/docker/devicemapper/mnt/e9f80849a2681e18549d3a4238cbf031e44052e36cd88a0abf041804b799b61c
152 sdc                                                                                       8:32   1  14.9G  0 disk 
153 └─sdc1                                                                                    8:33   1     2G  0 part /run/media/claneys/97f418a5-612f-44e9-b968-a19505695151
154 sda                                                                                       8:0    0 931.5G  0 disk 
155 ├─sda2                                                                                    8:2    0   500G  0 part 
156 │ ├─Shamash-home                                                                        253:2    0   150G  0 lvm  /home
157 │ └─Shamash-root                                                                        253:0    0    50G  0 lvm  /
158 └─sda1                                                                                    8:1    0    16G  0 part [SWAP]
159 ```
160
161 Copy, still from your host:
162
163 **Careful : Make sure to sync IO with sync command before unplug your SDcard. It could be corrupted if removed before all pending IO aren't done.**
164
165 ```bash
166 $ sudo cp ~/devel/docker/share/libafbwsc-dev-1.0-r0.cortexa15hf_neon.rpm /run/media/claneys/97f418a5-612f-44e9-b968-a19505695151/home/root
167 $ sync
168 ```
169
170 Insert the modified SDcard in your Porter board and boot from it. Your are ready to go.
171
172 ## Configure the AGL system
173
174 ### Virtual CAN device
175
176  Connected to the target, here is how to load the virtual CAN device driver and set up a new vcan device :
177
178 ```bash
179 # modprobe vcan
180 # ip link add vcan0 type vcan
181 # ip link set vcan0 up
182  ```
183
184 ### CAN device using the USB CAN adapter
185
186 Using real connection to CAN bus of your car using the USB CAN adapter connected to the OBD2 connector.
187
188 Once connected, launch ```dmesg``` command and search which device to use :
189
190 ```bash
191 # dmesg
192 [...]
193 [  131.871441] usb 1-3: new full-speed USB device number 4 using ohci-pci
194 [  161.860504] can: controller area network core (rev 20120528 abi 9)
195 [  161.860522] NET: Registered protocol family 29
196 [  177.561620] usb 1-3: USB disconnect, device number 4
197 [  191.061423] usb 1-2: USB disconnect, device number 3
198 [  196.095325] usb 1-2: new full-speed USB device number 5 using ohci-pci
199 [  327.568882] usb 1-2: USB disconnect, device number 5
200 [  428.594177] CAN device driver interface
201 [ 1872.551543] usb 1-2: new full-speed USB device number 6 using ohci-pci
202 [ 1872.809302] usb_8dev 1-2:1.0 can0: firmware: 1.7, hardware: 1.0
203 [ 1872.809356] usbcore: registered new interface driver usb_8dev
204 ```
205
206 Here device is named **can0**.
207
208 This instruction assuming a speed of 500000kbps for your CAN bus, you can try others supported bitrate like 125000, 250000 if 500000 doesn't work:
209
210 ```bash
211 # ip link set can0 type can bitrate 500000
212 # ip link set can0 up
213 # ip link show can0
214   can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
215     link/can 
216     can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 
217     bitrate 500000 sample-point 0.875 
218     tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
219     sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
220     clock 16000000
221 ```
222
223 ## Configure the binding
224
225 Configure the binding specifying in the JSON configuration file the CAN device(s) that it will to connect to. Edit file */var/lib/afm/applications/low-can-binding/0.1/can_buses.json* and change the CAN device name to the one you have :
226
227 ```json
228 {
229         "canbus":  "can0"
230 }
231 ```
232
233 If you have several specify CAN bus devices use an array:
234
235 ```json
236 {
237         "canbus": [ "vcan0", "can0" ]
238 }
239 ```
240
241 ## Run it, test it, use it !
242
243 You can run the binding using **afm-util** tool, here is the classic way to go :
244
245 ```bash
246 # afm-util run low-can-binding@0.1
247 1
248 ```
249
250 You can find instructions to use afm-util tool [here][afm-util], as well as documentation about Application Framework.
251
252 But you can't control nor interact with it because you don't know security token that **Application Framework** gave it at launch.
253
254 So, to test it, it is better to launch the binding manually. In the following example, we will use port **1234** and left empty security token for testing purpose:
255
256 ```bash
257 #  afb-daemon --ldpaths=/usr/lib/afb:/var/lib/afm/applications/low-can-binding/0.1/libs/ --rootdir=/var/lib/afm/applications/low-can-binding/0.1/ --port=1234 --token=
258 NOTICE: binding [/usr/lib/afb/afb-dbus-binding.so] calling registering function afbBindingV1Register
259 NOTICE: binding /usr/lib/afb/afb-dbus-binding.so loaded with API prefix dbus
260 NOTICE: binding [/usr/lib/afb/authLogin.so] calling registering function afbBindingV1Register
261 NOTICE: binding /usr/lib/afb/authLogin.so loaded with API prefix auth
262 NOTICE: binding [/var/lib/afm/applications/low-can-binding/0.1/libs//low-can-binding.so] calling registering function afbBindingV1Register
263 NOTICE: binding /var/lib/afm/applications/low-can-binding/0.1/libs//low-can-binding.so loaded with API prefix low-can
264 NOTICE: Waiting port=1234 rootdir=/var/lib/afm/applications/low-can-binding/0.1/
265 NOTICE: Browser URL= http:/*localhost:1234
266 NOTICE: vcan0 device opened and reading {binding low-can}
267 NOTICE: Initialized 1/1 can bus device(s) {binding low-can}
268 ```
269
270 Then connect to the binding using previously installed ***AFB Websocket CLI*** tool :
271
272 ```bash
273 # afb-client-demo ws://localhost:1234/api?token=
274 ```
275
276 You will be on an interactive session where you can pass ask directly to the binding API.
277
278 Binding provide at this moment 2 verbs, subscribe and unsubscribe, which can take argument by a JSON **event** object.
279
280 The argument value is the CAN message name as described in the JSON file used to generate cpp file for the binding.
281
282 To use the ***AFB Websocket CLI*** tool, a command line will be like the following :
283
284 ```
285 <api> <verb> <arguments>
286 ```
287
288 Where API will be : ***low-can***.
289 Verb : ***subscribe*** or ***unsubscribe***
290 Arguments : ***{ "event": "driver.doors.open" }***
291
292 ### Subscription and unsubscription
293
294 You can ask to subscribe to chosen CAN event with a call to *subscribe* API verb with the CAN messages name as JSON argument.
295
296 For example from a websocket session:
297
298 ```json
299 low-can subscribe { "event": "doors.driver.open" }
300 ON-REPLY 1:low-can/subscribe: {"jtype":"afb-reply","request":{"status":"success","uuid":"a18fd375-b6fa-4c0e-a1d4-9d3955975ae8"}}
301 ```
302
303 Subscription and unsubscription can take wildcard in their *event* value. 
304
305 To reveive all doors events :
306
307 ```json
308 low-can subscribe { "event" : "doors*" }
309 ON-REPLY 1:low-can/subscribe: {"jtype":"afb-reply","request":{"status":"success","uuid":"511c872e-d7f3-4f3b-89c2-aa9a3e9fbbdb"}}
310 ```
311
312 Then you will receive an event each time a CAN message is decoded for the event named *doors.driver.open*
313
314 ```json
315 ON-EVENT low-can/messages.doors.driver.open({"event":"low-can\/messages.doors.driver.open","data":{"name":"messages.doors.driver.open","value":true},"jtype":"afb-event"})
316 ```
317
318 Notice that event shows you that the CAN event is named *messages.doors.driver.open* but you ask for event about *doors.driver.open*.
319
320 This is because all CAN messages or diagnostic messages are prefixed by the JSON parent node name, **messages** for CAN messages and **diagnostic_messages** for diagnostic messages like OBD2.
321
322 This will let you subscribe or unsubcribe to all signals at once, not recommended, and better make filter on subscribe operation based upon their type. Examples:
323
324 ```json
325 low-can subscribe { "event" : "*speed*" } --> will subscribe to all messages with speed in their name. Search will be make without prefix for it.
326 low-can subscribe { "event" : "speed*" } --> will subscribe to all messages begin by speed in their name. Search will be make without prefix for it.
327 low-can subscribe { "event" : "messages*speed*" } --> will subscribe to all CAN messages with speed in their name. Search will be on prefixed messages here.
328 low-can subscribe { "event" : "messages*speed" } --> will subscribe to all CAN messages ending with speed in their name. Search will be on prefixed messages here.
329 low-can subscribe { "event" : "diagnostic*speed*" } --> will subscribe to all diagnostic messages with speed in their name. Search will be on prefixed messages here.
330 low-can subscribe { "event" : "diagnostic*speed" } --> will subscribe to all diagnostic messages ending with speed in their name. Search will be on prefixed messages here.
331 ```
332
333 You can stop receiving event from it by unsubscribe the signal the same way you did for subscribe
334
335 ```json
336 low-can unsubscribe { "event": "doors.driver.open" }
337 ON-REPLY 2:low-can/unsubscribe: {"jtype":"afb-reply","request":{"status":"success"}}
338 low-can unsubscribe { "event" : "doors*" }
339 ON-REPLY 3:low-can/unsubscribe: {"jtype":"afb-reply","request":{"status":"success"}}
340 ```
341
342 [OpenXC_to_AGL]: images/OpenXC_to_AGL.png "From OpenXC firmware to AGL binding"
343 [CAN_bindings_communication]: images/CAN_bindings_communication.png "Communication between CAN bindings and third applications"
344 [CAN_mapping]: images/CAN_level_mapping.png "CAN low and high level bindings mapping"
345
346 [USB_CAN]: http://shop.8devices.com/usb2can "USB CAN adapter recommended"
347 [OBD2_cable]: http://www.obd2cables.com/ "OBD2<->DB9 recommended cable"
348 [SDK_instructions]: http://docs.iot.bzh/docs/getting_started/en/dev/reference/setup-sdk-environment.html "Setup SDK environment"
349 [generator]: http://github.com/iotbzh/can-config-generator "AGL low level CAN binding Generator"
350 [afm-util]: http://docs.iot.bzh/docs/apis_services/en/dev/reference/af-main/afm-daemons.html#using-afm-util "afm-util usage"