netcarbench V3.4 User Manual

Transcription

1 netcarbench V3.4 User Manual Dominique Bertrand Nicolas Navet INRIA INRIA-RTaW B.P.239 B.P Villers-lès-Nancy Villers-lès-Nancy France France April 7, 2012 Contents 1 Introduction 1 2 Command line version - installation Linux (g++) Windows (Visual C++) Quick start Command line version - usage Print the help Generate message sets Graphical version - experimental in release Benchmark conguration Input format le Network specication Mandatory parameters Optional parameters Gateway Specication Simple gateway (compliant with 3.2 le format) Improved gateway (from 3.4 le format) Some examples Output format 12 7 Upcoming features 13 1 Introduction netcarbench is a GPL-licensed software that generates automotive message sets according to a set of user-dened parameters. netcarbench is available at Its purpose is to facilitate the assessment, the understanding and the comparability of techniques and tools used in the design of in-vehicle communication networks. Additional details about the design of the software can be found in [1]. In its current version netcarbench is able to generate CAN networks, possibly interconnected by gateways, and the sets of frames that are exchanged on these networks. Support for the generation of 1

2 signals, that can be useful for conguring FlexRay networks, has been temporarily removed. Users who need this feature should resort to version 2.x. Future releases will extend the architecture description to the system-level, and thus Electronic Control Units, tasks and runnables (i.e. elementary software modules) will be explicitely modelled. netcarbench is being developed at INRIA Lorraine in the TRIO team. netcarbench is registered by INRIA at Agence pour la Protection des Programmes (APP) under number IDDIN FR S.P You are welcome to get in touch with the authors to report bugs, suggest new features or contribute code at 2 Command line version - installation Documentation, source les and executables for Linux and Windows are freely available for download (under GPL license) at: Linux (g++) 1. Download the zip le of the sources for Linux in a directory $NETBASE of your choice and unpack it. prompt > cd $NETBASE prompt > unzip netcarbench.zip 2. Compile the binary: prompt > make This creates the binary netcarbench in the directory $NETBASE. 2.2 Windows (Visual C++) 1. Download the zip le netcarbench.zip of the sources for Windows and unpack it. 2. Open the project netcarbench.sln and compile. If VC++ is not installed on your machine and you want to use the executable provided with netcarbench, you will need to install the VC redistributable les that are freely available on the microsoft web site. 2.3 Quick start 1. Check that it works: prompt >./netcarbench -i body_config.xml -s 10 -r 1515 This will generate 10 message sets for a typical body network and create the corresponding XML les in the directory $NETBASE. 2. You may want to perform worst-case response time analysis directly on the generated xml les with NETCAR-Analyzer[3] (Windows only), or simulate and possibly perform fault injection on your networks with RTaW-Sim[4] (Windows and Linux). 3 Command line version - usage 3.1 Print the help prompt > $NETBASE/netcarbench --help 2

3 Figure 1: Graphical version of netcarbench - the left-hand screen capture shows the mandatory parameters while the right-hand capture shows the optional parameters. 3.2 Generate message sets prompt > $NETBASE/netcarbench -i <cong_le> -s <sets_number >-r <seed > --input <cong_le> -i <cong_le> To generate the message sets netcarbench will follow the specications given in <cong_le>that complies with the format given in Figure 2. --sets <sets_number > -s <sets_number > netcarbench will generate <sets_number > message sets. By default, 10 message sets are created. --random_seed <seed > -r <seed> netcarbench will use the seed value as seed of the random number generator. This is a way to reproduce the same sets of congurations. By default, the current time is used. 4 Graphical version - experimental in release 3.3 There is now an experimental graphical version that enables the user to specify the generation parameters without knowing the exact input le format. This graphical version is able to open, modify and save conguration le. Also, it is possible to directly generate a set of benchmarks from the GUI. The GUI, which is based on QT, is shown in Figure 1. This version is experimental and possesses some limitations: ˆ No gateway support - just single networks, ˆ Only Windows binaries are available for now. Linux versions should follow. 3

4 5 Benchmark conguration 5.1 Input format le netcarbench generates message sets which comply with the specications written in an XML conguration le provided by the user. The general pattern of a conguration le is given in Figure 2. <netcarbench-data version="3.2"> <can-network name=network_name bandwidth=network_bandwidth granularity=granularity > <network-load min=min_value max=max_value /> <nb-network-interfaces min=min_value max=max_value /> <fixed-station-loads> <station id=station_id value=station_load /> </fixed-station-loads> <fixed-station-queuing-policies fifo_ratio=value > <station id=station_id mode=station_mode > </fixed-station-queuing-policies> <frame-periods> <period value=frame_period weight=period_weight margin=period_margin prio_low_range=priority_low prio_high_range=priority_high /> </frame-periods> <frame-payloads> <payload value=frame_payload weight=payload_weight margin=payload_margin /> </frame-payloads> <offsets mode=osets_mode /> <jitters mode=jitters_mode value=jitters_value /> <deadlines mode=deadlines_mode value=deadlines_value /> </can-network> </gateway network_source=network_source_name network_target=network_target_name> <nb-frame-mappings min=min_frame_mappings max=max_frame_mappings /> <transmission-delay min=min_transmission_delay max=max_transmission_delay /> </gateway> </netcarbench-data> Figure 2: Pattern of a valid conguration le. 5.2 Network specication In the conguration le, the following set of parameters serves to specify a CAN network. We can distinguish between mandatory parameters (which must be provided to generate a network) from optional parameters (which may not be specied) Mandatory parameters 1. Name of the network <can-network name=network_name > ˆ Denition: Name of the network. ˆ Specication: The name of the network, network_name, is a unique identier: each specied can-network must have a dierent name. 2. Bandwidth of the network <can-network name=network_name bandwidth=network_bandwidth > ˆ Denition: Amount of data that can be sent over the network in a given period of time (i.e., the data rate). ˆ Specication: Fixed positive integer value bandwidth_value corresponding to the bandwidth. ˆ Unit: bandwidth_value in kbits/s (typically 500 or 250 for automotive systems). 4

5 3. Load of the network <network-load min=min_value max=max_value /> ˆ Denition: Percentage of bandwidth utilization (all frames considered). The worst-case overhead, including worst-case bit-stung, of CAN is considered (about 50% for 8 bytes of data). ˆ Specication: Range [min_value,max_value] of permitted values given in percentage, with 0 min_value max_value 1. Typically, for an automotive network, it ranges from 0.4 to Number of network interfaces in the network <nb-network-interfaces min=min_value max=max_value /> ˆ Denition: Total number of nodes (i.e., communication controllers) in the network. ˆ Specication: Range [min_value, max_value] of permitted values, with min_value, max_value N and 0 min_value max_value. Typically, for an automotive network, there are less than 20 nodes. 5. Periods of the frame <frame-periods> <period value=frame_period weight=period_weight margin=period_margin prio_low_range=priority_low prio_high_range=priority_high /> </periods> ˆ Denition: Time interval which separates two successive releases of the same frame on a given node of the network. ˆ Specication: If W denotes the sum of the period_weight values of all the frame periods, a new frame will be assigned a period of frame_period ms with a probability of (period_weight ± period_margin)/w. Furthermore, its priority will be chosen randomly in the range [priority_low, priority_high]. netcarbench ensures that each priority is unique in the frame set of one network. ˆ Unit: periods: frame_period in ms (integer value). priorities: priority_low, priority_high in the range [0, 2047] (as imposed by the standard). 6. Payloads of the frames <frame-payloads> <payload value=frame_payload weight=payload_weight margin=payload_margin/> </frame-payloads> ˆ Denition: Data payload of the frames. ˆ Specication: If L denotes the sum of the payload_weight of all the frame payloads, a new frame will be assigned a payload of frame_payload bytes with a probability of (payload_weight± payload_margin)/l. ˆ Unit: byte in the range [0, 8]. 5

6 5.2.2 Optional parameters 1. Period of the middleware communication task <can-network granularity=granularity > ˆ Denition: Period of the middleware task that creates the frames from the signals and issues the frame transmission requests. By default, granularity is set to 5 ms. This parameter is used for generating the frame oset values (RANDOM assignment, see Ÿ5). This parameter is also used by NETCAR-Analyzer when computing response times. If the frames are directly sent by the tasks (i.e., no middleware task), then the granularity is not meaningful (neither do osets). ˆ Specication: Fixed positive integer value granularity corresponding to the period. ˆ Unit: granularity in ms (real value). 2. Load of the stations <fixed-station-loads> <station id=station_id value=station_load /> </fixed-station-loads> ˆ Denition: Percentage of bandwidth utilization due to the frames sent by station with identier station_id. This is useful to model systems where a specic node contributes to a large share of the total bandwidth (typically, a body control module in automotive systems). ˆ Specication: Fixed value station_load. ˆ Unit: station_load is a real value [0, 1]. 3. Queueing policy of the stations <fixed_station_queuing_policies fifo_ratio=fo_ratio_value> <station id=station_id mode=station_mode /> </fixed_station_queuing_policies> ˆ Denition: option to specify specic queuing policy (for the outgoing frames) on certain stations. ˆ Specication: The attribute fifo_ratio is optional. When specied, it sets the ratio of stations with FIFO policy (among the stations that are not listed in the station list), otherwise all stations are HPF (except the stations that are listed as FIFO in the station list). The optional station list serves to specify the queuing policy for node with id station_id (station_id must be smaller than the minimal number of nodes). In the current version, the only possible values for station_mode are {FIFO, HPF}. ˆ Unit: fo_ratio_value is a real value [0, 1]. 4. Deadlines of the frames <deadlines mode=deadlines_mode value=deadlines_value /> ˆ Denition: option to specify deadlines for the frames. ˆ Specication: mode: deadlines_mode {FIXED, MAX_FIXED, PERIOD, FRACTION} * FIXED: for each frame, the deadline is set to the xed specied deadlines_value, * MAX_FIXED: for each frame, the deadline is set to min(period, deadlines_value) where period is the period of the frame that is considered, * PERIOD: for each frame, the deadline is set to the period of the frame (deadlines_value is not considered), * FRACTION: for each frame, the deadline is set to deadlines_value period where period is the period of the considered frame. 6

7 ˆ Unit: value: deadline_value 5. Osets of the frames * FIXED/MAX_FIXED: integer values in ms. * FRACTION: real value [0, 1] (percentage of time of the period). <offsets mode=osets_mode /> ˆ Denition: option to specify osets for the frames. ˆ Specication: mode: osets_mode {SYNCHRONOUS, RANDOM} 6. Jitters of the frames * SYNCHRONOUS: for each frame, the oset is set to 0, * RANDOM: for each frame, the oset value is randomly chosen between 0 and the period of the frame - 1 (integer value in ms), according to the granularity of the network (i.e., it is not possible to have osets that are not multiple of the communication task). A random oset assignment leads to better worst-case response times than in the synchronous case, but it of course not optimal and largely outperformed by dedicated algorithms [2]. <jitters mode=jitters_mode value=jitter_value ratio=jitter_ratio /> ˆ Denition: option to specify jitters for the frames. ˆ Specication: mode: jitters_mode {SYNCHRONOUS, RANDOM, FIXED} * SYNCHRONOUS: for each frame, the jitter is set to 0, * RANDOM: for each frame, the jitter value is randomly chosen between 0 and the period of the frame - 1 (integer value in ms), * FIXED: for each frame, the jitter is set to the xed specied jitters_value. ratio: jitters_ratio [0, 1] species the percentage of frames having jitters (not compatible with SYNCHRONOUS). The frames that are not selected to have jitters are assigned a jitter equal to 0. (this feature is not available i n the graphical version yet). ˆ Unit: in ms (integer value). 5.3 Gateway Specication This section of the input le allows to specify frames that are re-routed from one network to another (e.g., a frame produced by a network interface in the powertrain network is transmitted on the body network by an ECU that acts as a gateway). Several gateways can be specied in the conguration le. In the current version of netcarbench, the re-routing can only be done at the frame level (not the signals level), which means that gateways are actually bridges. There are two mutually exclusive ways to specify the gateways Simple gateway (compliant with 3.2 le format) With this solution, only uni-directional gateways can be dened. If two gateways of opposite direction are dened between the two same networks, then involved network interfaces are dierent (corresponding to the case where two dierent ECUs are involved). <gateway name=gateway_name network_source=network_source_name network_target=network_target_name > <nb-frame-mappings min=min_frame_mappings max=max_frame_mappings > <transmission-delay min=min_transmission_delay max=max_transmission_delay > </gateway> 7

8 1. Name ˆ Denition: unique identier. If not specied, the name will be automatically generated as network_source_name.network_target_name. 2. Number of frame mappings ˆ Denition: denes the number of frames which are transmitted by the gateway from the source network to the target network. ˆ Specication: Range [min_frame_mappings, max_frame_mappings] of permitted values, with min_frame_mappings, max_frame_mappings N and 0 min_frame_mappings max_frame_mappings. 3. Transmission delay ˆ Denition: denes the delay between the reception of the frame by the gateway on the source network and the re-transmission on the target network. ˆ Specication: Range [min_transmission_delay, max_transmission_delay] of permitted values, with min_transmission_delay, max_transmission_delay N and 0 min_transmission_delay max_transmission_delay. ˆ Unit: in µs (integer value) Improved gateway (from 3.4 le format) With this solution, both uni-directional and bi-directional gateways can be dened. In the case of a bi-directional gateway, the involved network interfaces are the same (corresponding to the case where one ECUs performs the gatewaying in both directions). 1. Name <gateway name=gateway_name > <direction> <networks network_source=network_a network_target=network_b > <nb-frame-mappings min=min_frame_mappings_1 max=max_frame_mappings_1 > <transmission-delay min=min_transmission_delay_1 max=max_transmission_delay_1 > </direction> <direction> <networks network_source=network_b network_target=network_a > <nb-frame-mappings min=min_frame_mappings_2 max=max_frame_mappings_2 > <transmission-delay min=min_transmission_delay_2 max=max_transmission_delay_2 > </direction> </gateway> ˆ Denition: unique identier. If not specied, the name will be automatically generated as network_a.network_b in the case of uni-directional gateway. In the case of a bi-directional gateway, two gateways are generated network_a.network_b-network_a_to_network_b and network_a.network_b-network_b_to_network_a. 2. Direction ˆ Denition: one or two directions for the ow of forwarded frames can be dened, corresponding respectively to the case where the gateway is unidirectional or bidirectional. The networks element species the direction. In the bidirectional case, the involved networks must match. 3. Number of frame mappings (for a specic direction) ˆ Denition: denes the number of frames which are transmitted by the gateway from the source network to the target network. 8

9 ˆ Specication: Range [min_frame_mappings, max_frame_mappings] of permitted values, with min_frame_mappings, max_frame_mappings N and 0 min_frame_mappings max_frame_mappings. 4. Transmission delay (for a specic direction) ˆ Denition: denes the delay between the reception of the frame by the gateway on the source network and the re-transmission on the target network. ˆ Specication: Range [min_transmission_delay, max_transmission_delay] of permitted values, with min_transmission_delay, max_transmission_delay N and 0 min_transmission_delay max_transmission_delay. ˆ Unit: in µs (integer value). 5.4 Some examples Valid conguration les are provided to generate frames for a typical body network (see body_config.xml in Figure 3), a typical powertrain network (see pwrt_config.xml in Figure 4) and to generate two networks which exchange frames via a gateway (see gateway.xml in Figure 5). The generation of signals is also possible, an example for a powertrain network is given (see pwrt_signals_config.xml). However signals generation is not yet supported in 3.x version, version 2.2 should be used for that purpose. <netcarbench-data version="3.2"> <can-network name="body_config" bandwidth="250" > <network-load min="0.45" max="0.55" /> <nb-network-interfaces min="15" max ="20" /> <fixed-station-loads> <station id="1" value="0.30" /> </fixed-station-loads> <fixed-station-queuing-policies fifo_ratio="0.30"> <station id="1" mode="fifo" /> <station id="2" mode="hpf" /> </fixed-station-queuing-policies> <frame-periods> <period value="50" weight="5" margin="1" prio_low_range="1" prio_high_range="200"/> <period value="100" weight="15" margin="3" prio_low_range="1" prio_high_range="600"/> <period value="200" weight="30" margin="5" prio_low_range="1" prio_high_range="1000"/> <period value="500" weight="15" margin="3" prio_low_range="200" prio_high_range="1000"/> <period value="1000" weight="10" margin="2" prio_low_range="600" prio_high_range="1500"/> <period value="2000" weight="5" margin="1" prio_low_range="1000" prio_high_range="2047"/> </frame-periods> <frame-payloads> <payload value="1" weight="1" margin="1"/> <payload value="2" weight="1" margin="1"/> <payload value="3" weight="1" margin="1"/> <payload value="4" weight="1" margin="1"/> <payload value="5" weight="2" margin="1"/> <payload value="6" weight="2" margin="1"/> <payload value="7" weight="2" margin="1"/> <payload value="8" weight="8" margin="2"/> </frame-payloads> <offsets mode="synchronous" /> <jitters mode="fixed" value="2" /> <deadlines mode="fraction" value="0.8" /> </can-network> </netcarbench-data> Figure 3: Source code for body_config.xml: an XML conguration le for the generation of sets of frames exchanged in a body network with FIFO queues for some ECUs. 9

10 <netcarbench-data version="3.2"> <can-network name="pwrt_config" bandwidth="500" granularity="5" > <network-load min="0.40" max="0.50" /> <nb-network-interfaces min="5" max ="15"/> <frame-periods> <period value="10" weight="5" margin="2" prio_low_range="50" prio_high_range="200"/> <period value="20" weight="10" margin="2" prio_low_range="100" prio_high_range="400"/> <period value="50" weight="20" margin="5" prio_low_range="250" prio_high_range="500"/> <period value="100" weight="10" margin="2" prio_low_range="300" prio_high_range="600"/> <period value="200" weight="5" margin="2" prio_low_range="400" prio_high_range="800"/> <period value="1000" weight="5" margin="2" prio_low_range="500" prio_high_range="1000"/> <period value="2000" weight="5" margin="2" prio_low_range="600" prio_high_range="1000"/> </frame-periods> <fixed-loaded_stations> <station id="1" value="0.30" /> <station id="2" value="0.20" /> </fixed-loaded_stations> <frame-payloads> <payload value="1" weight="2" margin="1" /> <payload value="2" weight="5" margin="2" /> <payload value="3" weight="5" margin="2" /> <payload value="4" weight="5" margin="2" /> <payload value="5" weight="10" margin="5" /> <payload value="6" weight="15" margin="5" /> <payload value="7" weight="20" margin="5" /> <payload value="8" weight="40" margin="5" /> </frame-payloads> <offsets mode="synchronous"/> <jitters mode="fixed" value = "2" /> <deadlines mode="max_fixed" value="30" /> </can-network> </netcarbench-data> Figure 4: Source code for pwrt_config.xml: an XML conguration le for the generation of sets of frames exchanged in a powertrain network where all nodes have HPF queues. 10

11 <netcarbench-data version="3.2"> <can-network name="powertrain" bandwidth="500" > <network-load min="0.4" max="0.5" /> <nb-network-interfaces min="5" max ="15" /> <fixed-station-loads> <station id="1" value="0.25" /> <station id="2" value="0.20" /> <station id="3" value="0.15" /> <station id="4" value="0.05" /> </fixed-station-loads> <frame-periods> <period value="10" weight="5" margin="2" prio_low_range="50" prio_high_range="200"/> <period value="20" weight="10" margin="2" prio_low_range="100" prio_high_range="400"/> <period value="50" weight="2" margin="1" prio_low_range="250" prio_high_range="500"/> <period value="100" weight="5" margin="2" prio_low_range="300" prio_high_range="600"/> <period value="200" weight="5" margin="2" prio_low_range="400" prio_high_range="800"/> <period value="1000" weight="5" margin="2" prio_low_range="500" prio_high_range="1000"/> <period value="2000" weight="5" margin="2" prio_low_range="600" prio_high_range="1000"/> </frame-periods> <frame-payloads> <payload value="1" weight="2" margin="1" /> <payload value="2" weight="5" margin="2" /> <payload value="3" weight="5" margin="2" /> <payload value="4" weight="5" margin="2" /> <payload value="5" weight="10" margin="5" /> <payload value="6" weight="15" margin="5" /> <payload value="7" weight="20" margin="5" /> <payload value="8" weight="40" margin="5" /> </frame-payloads> </can-network> <can-network name="body" bandwidth="250" > <network-load min="0.45" max="0.55" /> <nb-network-interfaces min="15" max ="20" /> <fixed-station-loads> <station id="1" value="0.30" /> <station id="2" value="0.15" /> <station id="3" value="0.10" /> </fixed-station-loads> <fixed-station-queuing-policies fifo_ratio="0.30"> <station id="1" mode="fifo" /> <station id="2" mode="hpf" /> </fixed-station-queuing-policies> <frame-periods> <period value="50" weight="2" margin="1" prio_low_range="1" prio_high_range="200"/> <period value="100" weight="15" margin="3" prio_low_range="1" prio_high_range="600"/> <period value="200" weight="15" margin="3" prio_low_range="1" prio_high_range="1000"/> <period value="500" weight="30" margin="5" prio_low_range="200" prio_high_range="1000"/> <period value="1000" weight="25" margin="5" prio_low_range="300" prio_high_range="1500"/> <period value="2000" weight="5" margin="1" prio_low_range="500" prio_high_range="1500"/> </frame-periods> <frame-payloads> <payload value="1" weight="1" margin="1" /> <payload value="2" weight="1" margin="1" /> <payload value="3" weight="1" margin="1" /> <payload value="4" weight="1" margin="1" /> <payload value="5" weight="2" margin="1" /> <payload value="6" weight="2" margin="1" /> <payload value="7" weight="2" margin="1" /> <payload value="8" weight="8" margin="2" /> </frame-payloads> <offsets mode="random" /> </can-network> <gateway name="can_gateway" > <direction> <networks network_source="body" network_target="powertrain" /> <nb-frame-mappings min="2" max="5" /> <transmission-delay min="0" max="500" /> </direction> <direction> <networks network_source="powertrain" network_target="body" /> <nb-frame-mappings min="5" max="10" /> <transmission-delay min="100" max="100" /> </direction> </gateway> </netcarbench-data> 11 Figure 5: Source code for gateway.xml: an XML conguration le for the generation of two networks exchanging some frames via a gateway.

12 6 Output format The V3.x output format of netcarbench is presented in Figure 6. RTaW-Sim [4] (>1.2.5) can directly import the V3.x netcarbench output le format, so you can easily simulate the congurations described in the generated xml les. The V3.x output format of netcarbench is at the time of writing not supported in a freely available version of NETCAR-Analyzer but V2.2 is still supported. However, upcoming releases will include a netcarbench V3.x import lter. <netcar-analyzer-data version="2.0.0"> <network name="net_name1" bandwidth="net_bandwidth1" granularity="net_granularity1"> <offset-list> <offset id="ncb_offset" /> </offset-list> <network-interface name="net_name1.node1" queuing="hpf"> <frame name="frame11" can-id="p11" period="t11" jitter="j11" deadline="d11" payload="l11"> <offset-value offset-id="ncb_offset" value="offset_11" fixed="false" /> </frame>... </network-interface> <network-interface name="network_name1.node2" queuing="hpf"> <frame name="frame21" can-id="p21" period="t21" jitter="j21" deadline="d21" payload="l21"> <offset-value offset-id="ncb_offset" value="offset_21" fixed="false" /> </frame>... </network-interface>... </network> <network name="net_name2" bandwidth="net_bandwidth2" granularity="net_granularity2"> <offset-list> <offset id="ncb_offset" /> </offset-list> <network-interface name="net_name2.node1" queuing="hpf"> <frame name="frame11" can-id="p11" period="t11" jitter="j11" deadline="d11" payload="l11"> <offset-value offset-id="ncb_offset" value="offset_11" fixed="false" /> </frame>... </network-interface> </network> <gateway name="gateway_name1" network-source="net_name_i" network-interface-source="net_name_i.node_n" network-target="net_name_j" network-interface-target="net_name_j.node_m" max-transmission-delay="gateway-delay"> <frame-mapping source="frame_k" target="gateway_frame1" /> <frame-mapping source="frame_l" target="gateway_frame2" />... </gateway>... </netcar-analyzer-data> Figure 6: Structure of the output XML le - rst, the description of the networks, then description of the gateways. This output le is decomposed in 2 parts: ˆ A list of CAN network description, each of which can be decomposed as follows A list of oset allocations (offset id) which denes one frame osets assignment (several choices for the oset might be considered, corresponding to dierent design choices). There is always a single oset assignment generated by netcarbench (though NETCAR-Analyzer and RTaW-Sim support several). By default, without the <offsets value=true /> tag (see Ÿ5.1), netcarbench set all oset values to 0. The list of network interfaces exchanging data on the CAN-bus. The frame waiting queue (outgoing stream) at the network interface can be either FIFO or HPF (Higher priority 12

13 rst), the latter being the default policy. Each network interface sends a set of frames, each described by its name, its can-id (priority), its period (ms), its data payload (in bytes, from 0 to 8), its jitter (ms) and its oset value (ms) dened for each offset-id. The osets of forwarded frames are not specied in the set of messages of the target networks (they can be read on the source networks). ˆ A list of gateway description, each of which describes the interaction between two networks, a source network and a target network. 7 Upcoming features Future releases will extend the architecture description to the system-level, and thus ECU, tasks and runnables will be explicitely modelled. A new possible output format le is under study: the TADL2 description language, that is being developed within the ITEA2 TIMMO-2-USE project. References [1] C. Braun, L. Havet, and N. Navet. NETCARBENCH: a benchmark for techniques and tools used in the design of automotive communication systems. In Proc. of the 7th IFAC International Conference on Fieldbuses and Networks in Industrial and Embedded Systems (FeT'2007), November Software and manual available at [2] M. Grenier, L. Havet, and N. Navet. Pushing the limits of CAN-scheduling frames with osets provides a major performance boost. In Proc. of the 4th European Congress Embedded Real Time Software., January [3] RealTime-at-Work. NETCAR-Analyzer: a CAN analysis tool. Freely available at realtimeatwork.com/software/netcar-analyzer/, [4] RealTime-at-Work. RTAW-Sim: a CAN simulation tool. Freely available at realtimeatwork.com/software/rtaw-sim/,