Dependable Systems of System DSoS IST-1999-11585 Dependable Systems of Systems Final demonstration of smart sensor interface Dependable System Composition 6 (DSC6) Report Version: Deliverable DSC6 Report Preparation Date: April 2003 Classification: Public Circulation Contract Start Date: 1 April 2000 Duration: 36m Project Co-ordinator: Newcastle University Partners: DERA, Malvern – UK; INRIA – France; CNRS-LAAS – France; TU Wien – Austria; Universität Ulm – Germany; LRI Paris-Sud - France Project funded by the European Community under the “Information Society Technology” Programme (1998-2002)
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Dependable Systems of System
DSoS
IST-1999-11585
Dependable Systems of Systems
Final demonstration of smart sensor interface Dependable System Composition 6 (DSC6)
Report Version: Deliverable DSC6 Report Preparation Date: April 2003 Classification: Public Circulation Contract Start Date: 1 April 2000 Duration: 36m
Project Co-ordinator: Newcastle University
Partners: DERA, Malvern – UK; INRIA – France; CNRS-LAAS – France; TU Wien – Austria; Universität Ulm – Germany; LRI Paris-Sud - France
Project funded by the European Community under the “Information Society Technology” Programme (1998-2002)
The Master/Slave Address (MSA) fireworks byte has been designed to generate a regular bit
pattern, which can be used by slave nodes with an imprecise on-chip oscillator for startup
synchronization (see figure 4).
IRG
UART−Frame 11 − bit
Star
t
LSB
MSB
Part
ity
Stop
TTP/A Slot − 13 bit
0 1 2 3 4 5 6 7
IBG
odd
Synchronize Pattern
Figure 4: Synchronization Pattern
The three least significant bits (bit 0...2) of the FB denote the round name. The remainding
bits (5 data and one parity bit) are used for error detection.
2.2.2 Properties of the Fireworks Byte
The generation of the firework codes had several requirements (see [9]): First, the byte
0x55 must be a part of the code because this regular bit pattern is also used for initial
synchronization of the slaves’ UARTs. Hamming distance should be maximized and the
Deliverable PCE4 7 Final Demonstration of Smart Sensor Interface
Smart Transducer Interface IST-1999-11585
resistance against burst errors should be optimal. The firework bytes are all sent with odd
parity and the lower three bits of the code have to be equal to the round number.
Code Generation: Because0x55 must be a member of the code, it was impossible to use
a cyclic redundant code (CRC) with the requested properties. So the code was created
by using an exhaustive search method.
Hamming Distance: The occurring Hamming distances are 4, 6, and 8. So the code will
detect all errors of weight less than 4.
Parity: The code includes an odd parity bit. So it will also detect all errors with an odd
weight above 4.
Burst Errors: Every possible burst error will be detected by the code.
Bulk Errors (force the bus to low or high): It is impossible to get a valid FB by setting
(or clearing) one or more adjacent bits. Therefore, it is impossible to corrupt a FB by
applying a direct voltage impulse to the bus and get another valid FB.
Error Exposure: Due to the fact that the byte is protected by a parity bit during transmis-
sion, we have an error exposure≥ 29−829 ≥ 98, 43%.
Error Pattern: There exist only 7 error patterns that will not be exposed under certain
circumstances. Four of them have weight 4 (0x02D , 0x11C , 0x131 , and0x1C2 ),
two error patterns have weight 6 (0x0DE and 0x0F3), and one has weight 8 (0x1EF ).
2.2.3 Types of Rounds
Multi-partner Rounds: A multi-partner round is used to transmit messages over the bus
from several nodes in predefined slots. Multi-partner rounds are scheduled periodi-
cally by the master. They are used to update real-time images, supporting the real-time
view of the cluster and also to periodically resynchronize the slaves’ clocks. It is pos-
sible to define 6 different multi-partner rounds per cluster.
Master-slave Rounds: The master of a TTP/A cluster can schedule master-slave (MS)
rounds to read data from an IFS file record, to write data to an IFS file record, or
to execute a selected IFS file record within the cluster.
The master-slave address (MSA) round specifies the node, the operation and the local
address of the desired data within the addressed node. The master-slave data (MSD)
round is used to transmit the data between master and slave.
Final Demonstration of Smart Sensor Interface 8 Deliverable DSC6
Dependable Systems of Systems Smart Transducer Interface
Broadcast Rounds: A broadcast round is a special form of MS round were the name of
the addressed node in the MSA round is set to0x00 . All nodes except those with
node alias0xFF are addressed by such a broadcast. Because more than one node
is addressed in such a round, only write and execute operations are permitted for
broadcast rounds. An example for such a broadcast is thesleepcommand, which puts
all nodes in a TTP/A cluster intosleep mode.
2.3 The Interface File System
Every TTP/A node has its own local interface file system (IFS) which is the source and
destination of the communication data. The IFS of a cluster consists of the local interface
file systems of all nodes in it. The IFS also serves as an interface to the application. All
relevant data of a node should be mapped into the IFS of this node.
The IFS of a single node can contain up to 64 files with a maximum of 256 four-byte records
in each file. The layout of the IFS is statically defined and each file of the IFS can have a dif-
ferent length. The only file which has to be implemented on all nodes is the documentation
file (file nr. 0x3D) which is used to identify the node.
2.3.1 File Structure
A file in the IFS can be viewed as an array of records. However, particular files can have
different lengths. Each record can store 4 bytes (32 bits) of data. For each node, up to 64
files can be defined. Every file must have a header record.
2.3.2 The Header Record
The first record of each file, which is the record with index0x00 , is the header record (see
figure 5). This record contains the information about the file.
Bit 7 of byte 0 is set if the file is read-only. The bits 5 and 6 hold the status of the file. The
status value is01b if the file is ok, otherwise the file is damaged. The remaining bits of these
bytes are reserved. Byte 1 gives the length of the file (in records) without the header record.
The next two bytes are internally used by the file-system.
Deliverable PCE4 9 Final Demonstration of Smart Sensor Interface
Smart Transducer Interface IST-1999-11585
BitNr. 7 6 5 4 3 2 1 0Byte 0 RO Status reservedByte 1 Length−1Byte 2 for file OSByte 3 for file OS
RO Read only: if set, file is read–onlyStatus The status of the file (ok if set to01b, damaged other-
wise).Length−1 Number of records in file decreased by one; index of
the last record; index start with 0 (header record)reserved These bits are reserved for further enhancements.for file OS Two bytes for use by the file operating routines.
Figure 5: IFS Header Record
Byte Nr. 0 1 2 3Record 0 HeaderRecord 1 Physical Name HiRecord 2 Physical Name Low
Header Header record of the documentation filePhysical Name Hi Upper 32 bit of the Physical NamePhysical NameLow
Lower 32 bit of the Physical Name
Figure 6: The Documentation File
2.3.3 Special files
The Documentation File: Every TTP/A node must contain a documentation file (file nr.
0x3D). This file is used to identify the node. The first and the second record after the header
record contains the unique physical name of the node which is an 8 byte (64 bit) integer (see
figure 6). This ID is stored in network order / big endian format (The MSB is stored in the
lowest byte).
The documentation file is always set to read only. Additional information about this node
can be added after the ID.
The Configuration File: The configuration file (file nr. 0x08; see figure 7) holds the
current logical name of the node and is also used by thebaptizingalgorithm (see section 2.5)
and with thesleepcommand.
Final Demonstration of Smart Sensor Interface 10 Deliverable DSC6
Dependable Systems of Systems Smart Transducer Interface
Byte Nr. 0 1 2 3Record 0 HeaderRecord 1 Cluster N. New LN Curr. LNRecord 2 Cmp. Phys. Name HiRecord 3 Cmp. Phys Name LowRecord 4 reservedRecord 5 Sleep
Header Header record of the configuration fileCluster N. Name of cluster to which the node belongsNew LN New logical name used by the baptize algorithmCurr. LN The current logical name of the nodeCmp. Phys. Name Hi Used for comparison by the baptize algorithmCmp. Phys. NameLow
Used for comparison by the baptize algorithm
Sleep Record used by the sleep command
Figure 7: The mandatory config File
Record0x01 holds in byte 3 the current logical name and in byte 2 the new logical name
used by thebaptizealgorithm. The records0x02 and0x03 contain the ID compare value
for the baptize algorithm. Record0x04 is reserved and record0x05 is used for the sleep
command.
The Membership File: It makes sense to implement this file on gateway or master nodes
while ordinary slave nodes will not benefit from the information gathered in this file. The
Membership file (file nr.0x09 ; see figure 8) contains two membership vectors of 256 bits
(32 byte) each. The logical name of each node is interpreted as an index to the 256 bits in the
membership vector. The first vector contains all slaves which have sent a live-sign during
the last multi-partner round. The second membership vector contains all slaves which have
responded to the most recent MS operation. To update the second membership vector the
master may fill empty MS slots by issuing read operations to the slaves documentation file,
which per definition must be present in every TTP/A node. The lowest bit of each of the
membership vectors referes to the highest Logical Name (0xFF).
The Round Sequence (ROSE) file: Only a master will benefit from the implementation
of the ROSE file. The ROSE file (file nr.0x0A ) specifies the sequence in which rounds
are scheduled by the master. In addition, start time and duration of this sequence can be
specified.
Deliverable PCE4 11 Final Demonstration of Smart Sensor Interface
Smart Transducer Interface IST-1999-11585
Byte Nr. 0 1 2 3Record 0 HeaderRecord 1Record 2Record 3Record 4 First MembershipRecord 5 VectorRecord 6Record 7Record 8Record 9Record 10Record 11Record 12 Second MembershipRecord 13 VectorRecord 14Record 15Record 16
Header Header record of the membership fileFirst MembershipVector
Membership vector of last sequence period
Second Member-ship Vector
Membership vector of master-slave responds
Figure 8: The Membership File
Byte Nr. 0 1 2 3Record 0 HeaderRecord 1 Active Sec. Start Sec. 2 Start Sec. 3
Header Header record of the ROSE fileActive Sec. 0: section two is active; 1: section three is activeStart Sec. 2 start record of section twoStart Sec. 3 start record of section three
Figure 9: Status Record of the ROSE File
The ROSE file is divided into three sections. The first section is the status record (record
nr. 0x01 ; see figure 9). The second and the third section each contain a sequence of round
names. At any given time, only one of the two sequences is active, the other is inactive. The
first byte of the status record defines which section is active. The second and the third byte
contain the start record of section two and three.
Final Demonstration of Smart Sensor Interface 12 Deliverable DSC6
Dependable Systems of Systems Smart Transducer Interface
Byte Nr. 0 1 2 3Record 2 StartRecord 3 TimeRecord 4 PeriodRecord 5 TimeRecord 6 Round Name IRG lengthRecord 7 Round Name IRG length
...
Start Time Start time of the round sequence (in 64 bit GPS formatdescribed in [19]
Period Time Length of the round sequenceRound Name Bits 0 ... 2 specify the name of the round, bit 7 is set if
this is the last round in the sequenceIRG length sets the length of the IRG following the specified
round. Must be in the range from 1 to 15.
Figure 10: Section two of the ROSE File
Sections two and three have the following format (see figure 10): The first two records hold
the start time of the sequence as an 64 bit (8 byte) integer value with a granularity of2−24 s.
The timer starts at the beginning of GPS time (January 6, 1980) plus an offset of238 seconds.
The next two records hold the period time of the whole sequence. All further records in the
section define a scheduled round. In the first byte of such a record, the three LSB define the
round. If the MSB is set, this entry is the last in this sequence. The second byte contains in
the lower 4 bits the number of slots in the inter round gap. Valid entries are0x01 , 0x02 , ...,
0x0F . The first entry of each sequence must be an MSA entry and every MSA entry must
have a complementary MSD entry.
2.3.4 Round Description List (RODL) files
The RODL file contains the information about the actions performed by a node for a partic-
ular round. The file names of the RODL files correspond to the round name.
The format of the RODL file is specific to the implementation of a given TTP/A node.
2.4 Master/Slave Rounds
The MS round is used by the master of a cluster to read data from an IFS file record, to write
data to an IFS file record, or to execute a selected IFS file record within the cluster.
Deliverable PCE4 13 Final Demonstration of Smart Sensor Interface
Smart Transducer Interface IST-1999-11585
IRG
DB Data ByteParameter BytePB
0x55 PB 0 PB 1 PB 2
FB
FB
0x49 DB 0 DB 1 DB 2 DB 3 Check
CheckPB 3
FF
FF DF
MSA Round
MSD RoundIRG
IRG
Multipartner RoundIRG
Multipartner Round
Figure 11: Master-slave round
BitNr. 7 6 5 4 3 2 1 0PB 0 EpochPB 1 Logical NamePB 2 File Name OP - CodePB 3 Record NameCheck Checkbyte
Epoch identifies the current epochLogical Name logical name of the addressed nodeOP - code specifies the operation which is performed (read, write
or execute)File Name name of the addressed fileRecord Name name of the addressed recordCheckbyte Checksum of the frame
Figure 12: Parameters in a MSA Round
An MS round is divided into two separate phases (see figure 11). The first is the MSA
round. During this phase, the master specifies (in a message to the slave node) which type
of operation is intended (read, write, or execute) and the address of the selected file record.
The format of the MSA round is shown in figure 12. The state of an issued MSA round
remains active until the arrival of a new MSA round.
The MSA round consists of six bytes (see figure 11). PB0 contains an epoch counter which
Final Demonstration of Smart Sensor Interface 14 Deliverable DSC6
Dependable Systems of Systems Smart Transducer Interface
provides the current epoch of the cluster internal time base. PB1 is the name of the addressed
node. PB2 specifies the operation type in bits 6 and 7 and the file which is addressed in the 6
low order bits. PB3 names the record, which is read from or written to. The parameter bytes
are followed by a check byte. This check byte is calculated as an exclusive or conjunction
over the parameter bytes and the FB.
In a subsequent MSD round, the master sends the firework which indicates that it is either
transmitting the record data or is waiting for the slave to transmit the requested record data,
depending on the operation specified in the previous MSA round. The message in the data
phase also consists of six bytes: The FB, four data bytes, and one check byte which is
calculated the same way as in the MSA round.
2.5 The Baptizing Algorithm
Until a logical name has been assigned to a node, it does not take part in the multi-partner
rounds. The baptize algorithm [5] is executed by the master to see which nodes are con-
nected to the TTP/A bus and to assign each of them a logical name, which is unique in this
TTP/A cluster.
This mechanism performs a binary search on all physical node names. A physical name is
unique for every TTP/A node within the entire universe of TTP/A nodes. The identification
of a new node takes 64 iterations. The master has to keep three 64 bit integer values,lo ,
hi , and the comparison identifierci . The values oflo andhi are only used internally to
calculate the newci values.
The variables oflo and hi are initialized to the minimum and maximum value of the
expected identifiers and move towards each other, untillo equalshi . In this case, the
identifier of a node is found and the master assigns a new alias to this node. This is done by
thebaptizeoperation.
The identifier comparison is done as follows:
• First, a lower limit for the node identifier is set by the master. This is done by perform-
ing a Master/Slave write operation to the records0x02 and0x03 of the mandatory
config file (0x08 ).
• Then the master requests an execute command on this records for all unbaptized nodes
(all with logical name0xFF ). The action which is assigned with this execute operation
is the comparison of the slave’s own unique identifier to the comparison identifier.
Deliverable PCE4 15 Final Demonstration of Smart Sensor Interface
Smart Transducer Interface IST-1999-11585
• In the corresponding MSD round of this Master/Slave round, all unbaptized nodes
whose own identifier is higher or equal than the comparison identifier write a data
frame with content0x00 in the first slot.
If no node responds to this command, then the value ofhi is set to the value ofci ,
otherwise lo is set to this value. If the value ofci andhi were equal and a node has
responded in this round, then the identifier of the new node has been found.
After finding the unique identifier of a node, a new logical name must be assigned to this
node. First, the new alias is written into byte0x02 of record0x01 of the mandatory config
file by a Master/Slave write operation. Because this operation addresses all unbaptized
nodes, in a second step, an execute operation is performed on this record. In this execute
operation, only the node whose unique identifier equals the comparison identifier, copies
this new logical name to its own logical name which is located in byte 0x03 of this record.
After this operation, the node takes part in multi-partner rounds and responds to Mas-
ter/Slave rounds with this new logical name.
2.6 CORBA
A CORBA gateway enables a cluster of smart transducers to share data (observations, con-
troll values, . . . ) with outer networks e. g., another smart transducer cluster. Both types
of data can be provided, real-time data (RS) and non time-critical data (DM and CP). A
CORBA object’s interface is defined in OMG IDL (Interface Definition Language). Such
an interface definition specifies the operations the object is prepared to perform. A detailed
description of the smart transducer’s interface in IDL can be found in [19].
For instantly response the gateway must held a copy of the real-time data within it’s own
IFS. Whereas non time-critical (remote) data are requested via MS rounds. To allow a global
interpretation of an observation the atomic triple
< name, instant, value>
is transmitted for each value. The instant is a 64 bit GPS related universal time, whereas a
name is composed ofClusterId , NodeId , FileNr andRecordNr .
Final Demonstration of Smart Sensor Interface 16 Deliverable DSC6
Dependable Systems of Systems Autonomous Mobile Robot
CORBA ORB Gateway
Active Master
Active Master
Active Master
Cluster A Cluster B Cluster C
Transducer Node
GIOP
Figure 13: Cluster of smart transducer networks
3 Autonomous Mobile Robot
This section describes the design and implementation of an autonomous mobile robot that
serves as a case study for the presented concepts on sensor fusion and time-triggered archi-
tectures. The robot is namedsmart carsince the robot consists of a four-wheeled model car
that is instrumented by a smart transducer network. The demonstrator’s components have
been developed during the last two years through the effort of several people.
The robot’s task is to navigate through a static obstacle course by perceiving its immediate
environment with the help of a combination of infrared and ultrasonic distance sensors.
Sensor fusion algorithms are used to integrate the sensor measurements into a certainty
grid, i. e., a description of the environment of the robot. Based on this information, a path
planning algorithm shall detect the most promising direction in order to detour obstacles in
front of the robot.
The robot consists of an off-the-shelf four-wheeled model car equipped with a fieldbus net-
work containing sensors, actuators, and control intelligence that enable an autonomous op-
eration of the car. Figure 14 depicts the smart car.
Deliverable PCE4 17 Final Demonstration of Smart Sensor Interface
Autonomous Mobile Robot IST-1999-11585
Figure 14: Smart Car
All employed sensors and actuators are commercial available components. In order to re-
solve interface mismatches, each sensor and actuator is implemented as a smart transducer,
thus being equipped with a small 8-bit microcontroller and a standardized network inter-
face. Furthermore, the network contains a control node and a master gateway node. The
control node hosts sensor fusion and control tasks. The gateway node enables the connec-
tion of monitoring hardware that supports the configuration of the network communication
and exports diagnostic data during operation. All transducer nodes are mounted on an area
of approximately 30 cm times 40 cm.
The software of the smart transducers are independent of the application. Each smart trans-
ducer contains the necessary software to instrument the local sensor or actuator and the
protocol interface software. The sensor fusion software is aware of the connected sensors
and the input requirements of the control application. The control application is decoupled
from the sensors, since it only uses data provided by the sensor fusion software and does
not depend on a particular sensor configuration. These properties are implemented in a
time-triggered sensor fusion model.
Final Demonstration of Smart Sensor Interface 18 Deliverable DSC6
Dependable Systems of Systems Autonomous Mobile Robot
3.1 Time-Triggered Sensor Fusion Model
Actuators Sensors
Environment Controlled Object
Transducer Level
Fusion/Dissemination Level
Control Level Control Application
Sensor Abstraction Layer
Fault Tolerance Layer Fault Tolerance Layer
Operator
Fault-Tolerant Image of the Environment
Man-Machine Interface
Fault-Tolerant Actuator Interface
Smart Transducers
Interface
Smart Transducers
Interface
Figure 15: Data flow in the time-triggered sensor fusion model
The time-triggered sensor fusion model incorporates properties like cyclic processing, com-
posable design, and introduces well-defined interfaces between its subsystems. Figure 15
depicts a control loop modelled by the time-triggered sensor fusion model. Interfaces are
illustrated by a disc with arrows indicating the possible data flow directions across the inter-
face. Physical sensors and actuators are located on the borderline to the process environment
and are represented by circles. All other components of the system are outlined as boxes.
The model distinguishes three levels of data processing with well-defined interfaces be-
tween them. Thetransducer levelcontains the sensors and actuators that interact directly
Deliverable PCE4 19 Final Demonstration of Smart Sensor Interface
The transducer level contains six sensors and five actuators. Each of the three infrared sen-
sors is equipped with a filtering mechanism that removes faulty sensor measurements and
smoothes the result. This filtering mechanism is locally implemented on the smart trans-
ducer, therefore belongs to the transducer level. The transducer level further contains a
position encoder node, a speed control node, a steering control node, and three servo nodes,
which are used to swivel around the infrared sensor nodes. At the fusion/dissemination level,
a servo control unit drives the servo nodes. The information of the current servo positions
and the measurements from the infrared sensors are fused by the robust certainty grid algo-
Final Demonstration of Smart Sensor Interface 26 Deliverable DSC6
Dependable Systems of Systems Autonomous Mobile Robot
rithm in order to create a description of the environment. Note that the robust certainty grid
algorithm provides a feedback value for each sensor that describes the current dependability
of that sensor. The result from the robust certainty grid algorithm is used by a navigation and
path planning unit at the control level. The measurements from the ultrasonic sensors are
fused to a unique observation using the confidence-weighted averaging algorithm. Based on
the available information the navigation and path planning unit decides about a navigation
path. This path is defined by turn angle and travel distance. A motion control unit hosted at
the fusion/dissemination level takes over the navigation path and generates the appropriate
values for the steering and speed control node while paying attention to the covered distance
provided by the position sensor.
3.3 Demonstrator Hardware
This section describes the relevant hardware components that form the demonstrator. Fig-
ure 18 depicts a categorization into three fields - mechanical hardware, electrical and elec-
tromechanical hardware, and TTP/A transducer hardware. The mechanical layer consists of
the main chassis of the smart car, which is an off-the-shelf four-wheeled model car fitted
with a wooden mounting board. The electrical and electromechanical hardware refers to the
physical sensors, power supplies, servos, LED indicators, and other components such as ad-
ditional power supply busses. The smart transducer hardware layer consists of the fieldbus
network with TTP/A nodes and the TTP/A communication bus.
3.3.1 Infrared Sensors
The Sharp GP2D02 infrared distance sensor is a low-cost distance sensor for the purpose
of measuring distances to objects within the range of 10–80 cm. It is designed for usage in
combination with small microcontrollers and is capable of taking measurements in varying
light conditions and against a wide variety of surfaces. The distance measuring technique
employed by the GP2D02 is triangulation. For this purpose, the GP2D02 emits light and
detects rays reflected by an object. By measuring the angle of the incoming rays and the
knowledge of the distance between the light source and drain, the distance from the sensor
to a reflecting object can be calculated. The output signal of the GP2D02 is proportional
to the angle and not the distance, thus the actual distance must be calculated by the host
microcontroller. Figure 19 depicts the conversion function from the sensor signal to the
distance of the reflective object. Objects closer than 10 cm are not recognized correctly.
Due to the static environment of the smart car, we can ensure that objects are recognized
Deliverable PCE4 27 Final Demonstration of Smart Sensor Interface
Autonomous Mobile Robot IST-1999-11585
Figure 18: Hardware parts of smart car
and avoided at distances greater than 10 cm. The conversion function can be approximated
by a hyperbolic function,
dist =KG
xSENSOR −K0
(1)
whereKG andK0 are sensor-dependent constants,xSENSOR is the sensor signal anddist is
the actual distance to the detected object in centimeters.
The GP2D02 needs a supply voltage within the limits of 4.4 V to 7 V and a suitable clock
signal for proper operation. A 4-pin connector is used to connect the four wires required by
the GP2D02: power, ground, clock in (VIn ), and signal output (VOut ). Figure 20 shows a
timing diagram of the process of initiating a measurement cycle and reading the data using
serial communication. To place the sensor in idle mode,VIn must be set to high. IfVIn
is high for more than 1.5 ms, the sensor will reset and go into idle mode. As shown in the
timing diagram, settingVIn to low initiates the measurement cycle. After the delay needed
by the sensor to take the reading, the sensor raisesVOut , signaling that it is ready to provide
the data.VIn will then be toggled between high and low. The output data is transmitted
Final Demonstration of Smart Sensor Interface 28 Deliverable DSC6
Dependable Systems of Systems Autonomous Mobile Robot
using a serial communication scheme, the most significant bit is transmitted first. Each bit
is valid shortly after the falling clock edge. After this cycle is finished,VIn should be held
high at least for the duration of the minimal inter-measurement delay.
The case of the sensor is a conductive plastic material. To insure reliable, noise-free mea-
surements, the case is connected to ground. Otherwise the sensor sometimes reports an
object even if none is present. Since theVIn signal must remain within the range -0.3 V to
+3.0 V while the output level of the microcontroller is around +5 V, two resistors are used
to achieve an appropriate signal level. Figure 21 depicts the circuit that interconnects sensor
and microcontroller.
3.3.2 Ultrasonic Sensors
For detection of objects at distances greater than 80 cm we use two Polaroid 6500 series
ultrasonic sensors. The sensing is performed by a sonic ping at a specific frequency that
travels from the transducer to the object and back. In the case of the Polaroid ultrasonic
module, 16 pings generated by transitions between +200 V and –200 V with a frequency of
220
210
200
190
180
170
160
150
140
130
120
110
100
90
80
70
60
500 20 40 60 80 100 120
Gray paper
White paper
Out
put v
alue
of
the
GP2
D02
Distance to reflective object L (cm)
Figure 19: Infrared sensor signal vs. distance to reflective object
Deliverable PCE4 29 Final Demonstration of Smart Sensor Interface
Autonomous Mobile Robot IST-1999-11585
around 50 kHz are used. The chirp moves radially from the source through the air at the
speed of sound, approximately 340msec
. When the chirp reaches an object, it is reflected in
varying degrees depending on the shape, orientation, and surface properties of the reflecting
surface. This reflected chirp then travels back towards the transducer. As the reflected
signal hits the transducer, a voltage is created, which is fed to a stepped-gain amplifier. To
avoid wrong measurements, the module only reports objects that have provided an echo to
subsequent pings.
Figure 22 describes the timing diagram for the ultrasonic sensor. A transition from low to
high at theINIT pin causes the generation of a chirp. When the sensor receives the reflected
signal, it raises theECHOpin. Thus, the transducer node is able to measure the duration
required by the sound to pass twice the distance chirp source to obstacle. Consequently, the
distance can be calculated by the following equation:
dist =tECHO [sec]− tINIT [sec]
2· 333[
m
sec] (2)
The measured durationtECHO has to be corrected by the initialization timetINIT . For the
employed modules, the valuetINIT is 0.55 msec. The sonic speed of 333msec
is valid for
sonic wave propagation in air of average humidity at 20 degree Celsius at sea-level pressure.
3.3.3 Servo Actuator
To move the infrared sensors through their sensor field some mechanism was needed. We
first tried to use stepper motors, which have the advantage that the angle can be determined
very exactly. However, the instrumentation of the motor coils needed extra hardware. So
we chose standard model car servos. They are cheap, lightweight, hard wearing, come in
many sizes, and have a standard control interface, that can be accessed by microcontrollers
without extra driver hardware.
VIn
VOut
MSB LSB
70ms 1.6ms 2ms
0.1ms 0.1ms
Figure 20: Timing diagram for the GP2D02 sensor
Final Demonstration of Smart Sensor Interface 30 Deliverable DSC6
Dependable Systems of Systems Autonomous Mobile Robot
3kΩ
3kΩ
Vcc
3V
2
GN
D 1
InOut
V
4
TTP/A Controller
Figure 21: Connection diagram for the GP2D02 infrared sensor
Vcc
INIT
ECHO
start ofmeasurement
echoreceived
end ofmeasurement
Figure 22: Timing diagram for the ultrasonic sensor
The Servo Interface Servos have a three-wire interface: ground, power, and control. The
input to the control line is a pulse width modulated signal from which all servo timings and
positions are derived. All servos have their own limitations concerning the ability to perform
a full turn. Convention states that applying a 1.5 ms signal holds the servo in neutral, a
1 ms signal turns it counter-clockwise to its maximum angle, and a 2 ms signal results in
a clockwise turn (see Figure 23). The signal must be repeated at least every 30–50 ms
otherwise the servo may start jittering and finally stop driving the output. The result would
be the loss of active hold on the desired position.
Connecting the servo The servo’s control line is connected directly to the microcon-
trollers output port. The power and ground wires are connected to the main line.
Deliverable PCE4 31 Final Demonstration of Smart Sensor Interface
Autonomous Mobile Robot IST-1999-11585
1ms 1.5ms 2ms
Figure 23: The servo control signal.
3.3.4 Steering Actuator
The steering actuator is used to select the tilt angle of the front wheels. For the steering of
the vehicle the exact same type of servo as for moving the infrared sensors is used. From
the interface view, the steering actuator is equal to the three servo actuators.
3.3.5 Speed Actuator
The digital speed control unit is instrumented very similar to the servo. Applying a 1.5 ms
signal puts the motor in neutral, while a pulse duration of 1 ms accelerates the car at full
speed forward. Accordingly, a pulse length of 2 ms results in full reverse speed.
While it is possible to regulate the forward speed by applying appropriate pulse-length be-
tween 1 ms and 1.5 ms, pulse lengths between 1.5 ms and 1.75 ms result in an active break,
i.e., the vehicle stops immediately respectively holds its current position. To regulate the
reverse speed pulse lengths between 1.75 ms and 2 ms can be used.
3.4 TTP/A Nodes
The network comprises 13 TTP/A fieldbus nodes. Some of them were designed especially
for this project while others have been adopted from existing applications (see [21]). Each
TTP/A node is equipped with a Motorola MC33290 ISO K Line Serial Link interface in
Final Demonstration of Smart Sensor Interface 32 Deliverable DSC6
Dependable Systems of Systems Autonomous Mobile Robot
Figure 24: Employed TTP/A node types (from left to right: master node with monitoringinterface, slave node based on AT90S4433 MCU, slave node based on ATMega128 MCUwith external RAM; scale in centimeters)
order to establish a communication at a bus speed of 9600 baud.1 All TTP/A nodes are im-
plemented in accordance to the standardized smart transducers interface specification [19].
Figure 24 shows the three node types that have been used with the smart car. Except for
transducer-specific circuitry, all nodes are implemented on commercial-off-the-shelf micro-
controllers on a printed circuit board of about 4 cm× 4 cm. The node hardware has been
designed at the Institut für Technische Informatik at the University of Technology in Vienna.
Figure 25 depicts the network schematic and placement of the 13 nodes on the smart car.
The following paragraphs describe the hardware of the nodes employed in the smart car:
Master node: The master node consists of an Atmel AT90S8515 microcontroller and is
clocked by a 7.3728 MHz quartz that allows standard baud rates for the hardware
UART. The Atmel AT90S8515 microcontroller is a low-power CMOS 8-bit micro-
controller based on the AVR RISC architecture. It features 8 KB of in-system pro-
grammable flash, 512 bytes of SRAM and 512 bytes of in-system programmable
EEPROM. It also has one 8-bit and one 16-bit timer/counter with separate prescaler
and a programmable serial UART.
The master has full access to the file system of all nodes in the network, and is also
used as a gateway to other networks. The gateway provides a monitoring interface for
accessing the IFS contents of any node in the network. Thus, a monitoring tool on a
1The performance of the particular nodes also allows higher transmission rates up to 38400 baud, howeverwe have chosen 9600 baud in order to show the capability of TTP/A to provide a high net bandwidth due to itshigh data efficiency.
Deliverable PCE4 33 Final Demonstration of Smart Sensor Interface
Deliverable PCE4 47 Final Demonstration of Smart Sensor Interface
Fieldbus Gateway IST-1999-11585
4 Fieldbus Gateway
To provide an easy to use and universal monitoring access to smart transducer networks, we
developed a PCMCIA gateway card (figure 33). It is the intention of the following section
to describe the design objectives, the implementation and to provide an evaluation of the
gateway card.
Figure 33: Printed circuit board of PCMCIA gateway card in comparison to size of 2 Eurocoin
4.1 Design Objectives
As this gateway should be able to operate in a real-time environment, the deterministic
structure given from this environment should be contained by using this gateway. We have
identified the following requirements:
Connect different real-time hierarchies: For example it should be possible to connect a
TTP/A node to a TTP/C host.
Possibility for real-time communication: Interconnected clusters should be able to com-
municate with each other in a hard real-time way, which means a bounded message
delay with low jitter.
Standardized interface: Implementing a widely used and adopted interface provides reli-
ability because it has been often tested and approved. Besides, easy integration and
use in future systems is given.
Final Demonstration of Smart Sensor Interface 48 Deliverable DSC6
Dependable Systems of Systems Fieldbus Gateway
Flexibility of connections: The design should be applicable for many different applica-
tions and a variety of fieldbuses.
Integration into the fieldbus: The gateway should provide full access to the fieldbus net-
work.
No property mismatch on connecting interfaces:This directly relates to the decision of
the interface, that has to avail the different property dimensions [14].
Clock synchronization: In order to achieve a global synchronized time, synchronization
within the network hierarchies must be possible.
Special care has to be taken when selecting a physical interface for the gateway. A collection
of possible interfaces is examined in [24]. Four possibilities have been considered regarding
their suitability:
RS232: A gateway using RS232 has already been implemented and is in use for monitoring
low-speed TTP/A networks. Although being a cheap and easily applicable solution,
the serial connection is naturally message-orientated. This leads to a change of real-
time semantics when shared memory information has to be mapped onto messages,
which poses a good example for a property mismatch.
USB: USB offers the isochronous mode, which allows to request an amount of bandwidth
for exclusive use and is therefore suited for real-time applications. Another benefit
would be the ability to connect more than one fieldbus-master device to the USB-
bus and therefore making the gateway a multi-point gateway. However, in general
the USB alternative suffers from the same property mismatch problem as the RS232
solution.
Dual-ported RAM: The dual-ported RAM provides a good architecture for real-time ac-
cess, as it supports a direct access to the fieldbus-masters memory and variables. The
disadvantage comes from the scalability, when multiple fieldbus devices have to be
integrated.
Ethernet: Ethernet offers a standard interface with high bandwith. The disadvantage lies in
the Carrier Sense Multiple Access / Collition Detection (CSMA/CD) access control,
since the possibillity of collitions makes real-time communication impossible unless
all nodes on one Ethernet segment follow a TDMA scheme for bus arbitration.
Deliverable PCE4 49 Final Demonstration of Smart Sensor Interface
Fieldbus Gateway IST-1999-11585
4.1.1 Considerations for Implementation
Taking into account the facts listed in Section 4.1, the decision was made towards the dual-
ported RAM, considering it the best approach to preserve real-time behavior. On access via
the PCMCIA interface from a TTP/C host or laptop-computer, the integration can be done
very easily. Therefore, the considerations are as follows:
Minimal hardware resources: If possible, single chip solutions should be used to reduce
the overall system cost.
RAM size about 1 KB: This reflects a typical TTP/A node specification for reasonable ap-
plications.
Flexibility: The gateway should support the interconnection of different fieldbus types
(e. g., TTP/A, CAN) to various host networks.
Commercial hardware: As far as possible, available and standardized hardware that has
proven its reliability should be used.
Device driver availability: When connecting the gateway to the higher level hierarchy, ac-
cess to the card must be given within the three interface types: real-time service (RS),
diagnostic and management (DM) interface, and configuration and planning (CP) in-
terface.
4.1.2 Design Evaluation
To our knowledge, there does not exist any commercial PCMCIA card providing an interface
to an MCU via dual-ported RAM that would be suitable for our purposes, so a dedicated
design has to be conceived. After having a general look on the market of available PCMCIA
cards, it is noticed that the market has shrunken mainly to the network- and modem-card
sector. As a result, single PCMCIA interface chips are no longer available because this
service is already integrated in application dedicated chips. This means that the PCMCIA
interface logic has to be implemented from scratch. The whole design has to be made on
a 54 mm× 85.6 mm area, the dimension of a PCMCIA card. Only chips below a height
of 2.8 mm (on top) respectively 1.1 mm (on bottom) can be used, unless invoking Chip-in-
PCB2 design. Moreover, several other logic elements (reset, etc.) have to be added, so the
2This refers to a special type of board design, where an area of the printed circuit board (PCB) is cut out inorder to be able to solder the according chip from beneath to reduce height.
Final Demonstration of Smart Sensor Interface 50 Deliverable DSC6
Dependable Systems of Systems Fieldbus Gateway
chip count is expected to increase rapidly. To cover this uprising and due to the fact that the
design changes during ongoing development, we decided to use a Field-Programmable Gate
Array (FPGA), which allows the integration of many functions into one component and
therefore saves precious space. Furthermore, a FPGA provides an easy way for applying
design changes in future. Since the card also holds an MCU for the implementation of
a fieldbus node, a serial PROM used for FPGA configuration can be omitted. A simple
bootloader programm running at the MCU may overtake this configuration task.
4.2 Implementation
This gateway card was designed to connect various types of fieldbuses to high-level hierar-
chies. Due to its flexible architecture, reconfigurations can be made and the possibility of
implementing extended functions is given. Since it uses a dual-ported RAM for exchange
of data, it is ideal for applications depending on real-time operations.
The following purposes are intended:
• to provide a connection from TTP/C via the PCMCIA interface to the TTP/A fieldbus.
• to be able to communicate from TTP/C with the CAN fieldbus.
TTP/A
TTP/C
CAN
Figure 34: Gateway Functionality
Thus, PCMCIA card is a three point gateway (see figure 34). A communication from TTP/A
to CAN would be also possible, but is not covered in this implementation. The TTP/A
Deliverable PCE4 51 Final Demonstration of Smart Sensor Interface
Fieldbus Gateway IST-1999-11585
interface is implemented in the MCU. By reprogramming the MCU, other fieldbusses like
LIN [1] can be interfaced as well.
To fulfill the first objective, a design with a dual-ported RAM has proven to be a good
approach towards a solution that fully supports real-time behavior. Since the card already
hosts an FPGA to provide the PCMCIA interface, it is advantegeous to use an FPGA device
that includes dual-ported RAM. Since the configuration of the used FPGA is located in
volatile memory, it always needs reprogramming after power up to become operative. This
is done by a bootloader via the onboard MCU. As a further benefit, this approach enables
an easy and unlimited reprogramming of the FPGA.
For the second purpose a special component is required: the CAN-Controller. This is a
ready-made commercial chip that takes care of the whole CAN-related communication.
4.2.1 Card Components
As the functional diagram in Figure 35 presents, the card consists of the four main parts:
• PCMCIA Interface Logic
• Dual-ported RAM
• MCU
• CAN-Controller
The PCMCIA interface is intended to support the connection to a high-level network. This
means, that this side of the gateway can be connected to a TTP/C host or a laptop-computer,
or any device that offers PCMCIA insertion. This card is designed to be PCMCIA 2.1
compliant, which is the last standard derived and therefore is backwards-compatible to 8-bit
hosts. So it can be used in every PCMCIA slot.
The design uses the following chips:
Xilinx Spartan-II FPGA: The product of choice is the Xilinx Spartan-II Family, which
also offers the possibility to implement dual-ported RAM into the chip. For a lookout
on FPGA chip possibilities.
Atmel ATmega128 MCU: This is an 8-bit microprocessor, which offers many I/O pins and
128 KB of flash memory.
Final Demonstration of Smart Sensor Interface 52 Deliverable DSC6
Dependable Systems of Systems Fieldbus Gateway
CAN IF Logic
PCMCIAHost BusAdapter
HBA DriverBus
TTP/A Network
PCMCIA
IF
Logic
RAM
CAN Controller
MCU
TTP/A
Master
Dual Ported
Driver
Bus
FPGA
PCMCIA Gateway Card
TTP/A Nodes
CAN Network
CAN Nodes
Figure 35: Gateway Architecture
Philips SJA1000 CAN Controller: This common chip offers two different modes of oper-
ation: BasicCAN Mode and PeliCAN Mode. For more information please see [22].
Philips TJA1050 CAN Transceiver: The chip is used as interface between the CAN Con-
troller and the physical CAN bus.
Motorola ISO K line serial link interface: This is a serial link bus interface for bi-
directional half-duplex communication. This single-wire bus interface is widely used
in the low-cost automotive domain.
Maxim RS485/422 Transceiver:This chip is a differential bus driver supporting the
RS485 standard.
The following connectors are offered by the card as shown in table 5:
4.2.2 Memory Layout
Figure 36 gives an overview on the memory layout of the dual-ported RAM within the
FPGA. The RAM can be accessed from two sides. The left side in the figure corresponds to
Deliverable PCE4 53 Final Demonstration of Smart Sensor Interface
Fieldbus Gateway IST-1999-11585
Connector Description
PCMCIA connector Connection to host computerJTAG (for FPGA) For debugging of FPGA from any PC via paral-
lel cable and JTAG interfaceJTAG (for Atmel) For programming and debugging of the MCURS485 Connector Connection to twisted pair RS485 networksISO K-line Connector Connection to single-wire network (e.g. TTP/A
or LIN)CAN Connector Connection to CAN fieldbus
Table 5: Connectors implemented on the PCMCIA card
the PCMCIA host, while the right one is dedicated to the MCU. Since the Atmel mega128
maps external RAM at0x8000 the address-ranges differ.
07FF 0x87FF0800 0x8800
0x80000000
0x00000x0000
0x0000 (0x0100 Bytes)IFS Headers
Dual−Ported RAM(0x0700 Bytes)
0x0000 00FF 0x80FF
(0x0100 Bytes)CAN−Controller
notimplemented
0x0000 08FF09000x0000
0x88FF0x8900
0xFFFF
FFFF
Add
ress
spa
ce f
or a
cces
sfr
om P
CM
CIA
hos
t
Add
ress
spa
ce f
or a
cces
sfr
om A
TM
ega1
28
0x03FF
0x0000 0100 0x8100
Figure 36: Memory layout of the dual-ported RAM
The PCMCIA host addresses0x0000 to 0x00FF contain information about the organiza-
tion of the IFS for the TTP/A network (see Section 4.2.4). The addresses0x0100 up to
0x07FF host the IFS contents. The area from0x0800 up to0x08FF is used to interface
the CAN-Controller.
4.2.3 Client Drivers and Kernel Modules
For each PCMCIA card a client driver is required. This driver reads the card information
structure (CIS) to determine the card’s resource requirements, initializes the host bus adapter
Final Demonstration of Smart Sensor Interface 54 Deliverable DSC6
Dependable Systems of Systems Fieldbus Gateway
(HBA), and configures the card. According to the PCMCIA specification [20], this driver
is called the card enabler. This driver uses functions provided by card services.
Accessing the card via PCMCIA requires several components (client driver, card services,
socket services, CIS). A registration process permits access to card services and allows the
driver to subscribe events the driver wants to be informed of. The following paragraph gives
a short overview to the configuration process:
The registration process starts with a validation of the installed card services. This task is
done by the functionGetCardServicesInfo . Afterwards, card services can be reg-
istered by using the functionRegisterClient for memory clients. This function also
enables the reception of insertion, removal, and call-back events. Furthermore, a handle is
returned to the client to allow identification on future calls. The client must be aware of
call-backs from card services when the card is inserted respectively removed. On insertion,
the configuration table within the card information structure (CIS) must be read. The client
driver can use the functionsGetFirstTuple , GetNextTuple , andGetTupleData
to process the CIS. Important values are the device type, which is set toDPRAMin case of the
gateway card, and the memory size. If the device type differs fromDPRAM, the driver has to
return an error-code indicating that the card has not been found. Using the size parameter,
the address space of the card´s memory is determined. Note that function names given here
are taken from the PCMCIA specification [20] and can differ in some implementations.
Shared IFS
Local IFS
Gateway
TTP /A Master
Local IFS TTP/A Slave
Local IFS TTP/A Slave
Local IFS TTP/A Slave
TTP
/A B
us
Figure 37: Network structure of the distributed interface file system
Deliverable PCE4 55 Final Demonstration of Smart Sensor Interface
RO Read only: if set, file is read–onlyStatus The status of the file (ok if set to01b, damaged other-
wise).Length−1 Number of records in file decreased by one; index of
the last record; index start with 0 (header record)reserved These bits are reserved for further enhancements.Pointer Locates the file relative to start of dual-ported
RAM(record address).
Figure 38: IFS header record in the dual-ported RAM
4.2.4 Accessing the IFS from the Gateway
A part of the IFS (Interface File System) of a TTP/A master is mapped into a shared memory
realized by a dual-ported RAM. This memory is accessed by a gateway that either directly
accesses the visible IFS or performs a master-slave request to poll the required data. Fig-
ure 37 depicts the network structure of the distributed interface file system.
The first0x0100 bytes of the dual-ported RAM contain the header records (see figure 38)
of all IFS files of the gateway. This header records contain pointers, which are used to locate
files that are directly mapped into the shared IFS.
The pointer value holds the start address of each IFS file (without header) relative to the
start of the dual-ported RAM in records (4 bytes). For IFS files that are not mapped into the
shared memory, this value is set to0x0000 . These files and files located on other nodes
can be accessed via a special gateway request file.
4.2.5 Mapping of Gateway Request onto the Interface File System
All master-slave requests are mapped onto the gateway request file (file0x0c ). This file
must be located in the shared IFS. Byte 0 of record 1 of this file specifies the number of
available gateway requests (see figure 39). Following this number is the respective number
of buffers for requests.
A gateway request is stored according to the format depicted in table 6.
Final Demonstration of Smart Sensor Interface 56 Deliverable DSC6
Dependable Systems of Systems Fieldbus Gateway
n Request 1 Request n
Figure 39: Gateway request file
Byte index Element name Size in bytes0 Status 11 Cluster name 12 Node alias 13 File:Op-Code 14 Record number 15 Checksum (addr.) 16 Data bytes 410 Checksum (data) 1
Table 6: Format of a gateway request
Each request takes 11 byte. The status byte at the beginning indicates if the request is passive
(0x00 ), active (0x01 ), or done (0x02 ). If an error has occured during execution, the status
byte contains an error code (≥0xf0 ).
A master-slave request from the gateway side is thus performed as follows:
1. Select an entry with astatusbyte0x00 . Be aware that astatus≥ 0x02 may indicate
that the request has been performed, but has not yet been processed by the gateway.
3. In case of a write operation, the containts of the target record are also written into the
four byte data buffer (starting at index 6) of the request. The checksum is generated
by the master.
4. Change status byte to0x01 . This sets the entry to active and causes the master to
resolve the request.
5. Wait until a change of the status byte. It is possible to initiate an other request during
that time.
6. A status byte of0x02 indicates that the request has been well performed, otherwise
the status byte contains an error code. If the status byte shows0x02 , it is now possible
to read the results from the data field, in case of an read or execute operation.
Deliverable PCE4 57 Final Demonstration of Smart Sensor Interface
Fieldbus Gateway IST-1999-11585
7. If the results from the request have been consumed, set the status byte to0x00 in
order to allow new requests.
Note that there can be more than one active request at a time. The master may answer these
requests in an arbitrary order. The data bytes can be either written by the TTP/A master or
the gateway, according to the specified operation.
Establish Connection: Actually, when the IFS is accessed from the TTP/C host, an IFS
address is sent to the driver at the higher level network, which translate the IFS address into
a memory address and than retrives the information from the dual-ported RAM via a simple
RAM read. As a result, the driver requires knowledge of the virtual address given from card
services whenever a card is inserted.
4.2.6 CAN Access from a TTP/C host via PCMCIA
Via the onboard CAN controller it its possible to send/receive messages over the CAN field-
bus network. In general, the registers of the controller are mapped into the address-range
of the PCMCIA bus according to Figure 36. The chip chosen for the CAN interface is the
Philips SJA1000 because it offers a circular buffer and is commonly used.
4.3 Throughput Evaluation
Option Register Data Width Calculated ThroughputRead Access
16-bit 16-bit 1.60µs per access≈ 1.25 MByte/s8-bit 16-bit 3.23µs per access≈ 619 kByte/s8-bit 8-bit 1.61µs per access≈ 623 kByte/s
Write Access16-bit 16-bit 1.67µs per access≈ 1.18 MByte/s8-bit 16-bit 3.26µs per access≈ 613 kByte/s8-bit 8-bit 1.66µs per access≈ 602 kByte/s
Table 7: PCMCIA throughput
A measurement determines the PCMCIA data throughput in both 8-bit and 16-bit mode.
The PCMCIA Host Bus Adapter (HBA) offers several registers [17] for configuration and
signaling. To switch the HBA between 8/16-bit the PCMCIA Port Size (PPS) field of the
Final Demonstration of Smart Sensor Interface 58 Deliverable DSC6
Dependable Systems of Systems Summary and Conclusion
option register is used. If the register field is set to 0, the port size is 8 bit, if the register field
is set to 1, the port size is 16 bit.
Therefore, the HBA is either put in 8-bit or 16-bit mode and a test program is executing a
sufficient number of writes or reads to produce a meaningful result. The measuring data and
computed access time is shown in table 7.
5 Summary and Conclusion
This report describes the principles of operation of the smart transducer interface and the
design and implementation of a case study.
The smart transducer interface specifies two generic digital communication interfaces (LIFs)
to a sensor bus: a time-triggered LIF that periodically transmits the current measured val-
ues, and a non-time-critical event-triggered LIF that is used for sensor configuration and
diagnostics. By hiding the internal structure of the sensor, the smart sensor technology can
contribute to a reduction in complexity at the system level. The smart transducer interface
specification supports applications of several fields, namely time-triggered real-time sys-
tems, smart transducer interfaces, monitoring and configuration, sensor fusion, and robot
navigation.
The autonomous mobile robot (“smart car”) acts as a case study for the smart transducer in-
terface. The software is structured according to the three-level model of the Time-Triggered
Sensor Fusion Model: The node level contains local self-contained software of the trans-
ducer nodes. Communication among the nodes is strictly time-triggered. The cluster level
contains the software that generates the glue between the sensors and the actuators and the
control application. The cluster level hosts the sensor fusion algorithms, that enable a con-
sistent view of the environment regardless of sensor deficiencies. The control application
level hosts the navigation code and handles the user interface. The system architecture al-
lows monitoring of all relevant node properties without affecting the real-time behavior of
the application. Configuration tools can access the cluster via an RS232 interface.
The PCMCIA gateway card provides an alternative implementation of a gateway. While the
RS232 solution had to map the shared memory-based Interface File System (IFS) concept to
a message-based interface, this property mismatch can be overcome by the used PCMCIA
interface, which is also based on a shared memory. Using this shared memory, the gateway
card provides access to the Real-Time Service (RS), the Configuration and Planning (CP),
and the Diagnostics and Management (DM) interfaces.
Deliverable PCE4 59 Final Demonstration of Smart Sensor Interface
References IST-1999-11585
5.1 Contributions to DSoS
From a number of different ideas for designing a smart transducer interface the notion of
the Interface File System emerged as the central concept for an understandable and flexible
generic smart transducer interface. With the start of the DSOS project, this concept was
implemented and expanded. We consider the very positive experience with a number of
prototype implementations of this interface on different low-cost micro-controllers. This
work has already generated a high level of industrial interest.
In order to achieve interoperability between subsystems that have been designed in different
organizations at different times, legal or de-facto standards for the interaction of subsystems
are necessary. The standardization of the smart transducer interface by the Object Manage-
ment Group provides such a standard and is thus an important contribution in the planned
dissemination actions within the DSoS project.
The implementation of the smart transducer interface in the smart car and the PCMCIA
gateway card has provided a proof-of-concept of the interfacing strategies regarding com-
posability, dependability, and event-triggered versus time-triggered linking interfaces.
5.2 Future Work
The DSoS project has provided a well-defined fundament for the design and implementa-
tion of further concepts. In a more focused view, future work will be the integration of
time-triggered and event-triggered services into a dependable system, the development of
computer-aided support tools that support a remote monitoring and configuration of a smart
transducer network, and the integration of simulation and test methods for smart transducer
networks, and
References
[1] Audi AG, BMW AG, DaimlerChrysler AG, Motorola Inc. Volcano Communication Technologies AB,Volkswagen AG, and Volvo Car Corporation. LIN specification and LIN press announcement. SAEWorld Congress Detroit, http://www.lin-subbus.org, 1999.
[2] Dependable Systems of Systems (DSoS), IST-1999-11585.Dissemination and Use Plan, 2002. Availableat http://www.newcastle.research.ec.org/dsos/.
[3] P. Dierauer and B. Woolever. Understanding smart devices.Industrial Computing, pages 47–50, 1998.
[4] A. Elfes. Using occupancy grids for mobile robot perception and navigation.IEEE Computer, 22(6):46–57, 1989.
Final Demonstration of Smart Sensor Interface 60 Deliverable DSC6
Dependable Systems of Systems References
[5] W. Elmenreich, W. Haidinger, P. Peti, and L. Schneider. New node integration for master-slave fieldbusnetworks. InProceedings of the 20th IASTED International Conference on Applied Informatics (AI2002), pages 173–178, February 2002.
[6] W. Elmenreich and P. Peti. Achieving dependability in a time-triggered network by sensor fusion. InProceedings of the 6th IEEE International Conference on Intelligent Engineering Systems (INES), pages167–172, Opatija, Croatia, May 2002.
[7] W. Elmenreich, L. Schneider, and R. Kirner. A robust certainty grid algorithm for robotic vision. InProceedings of the 6th IEEE International Conference on Intelligent Engineering Systems (INES), pages25–30, Opatija, Croatia, May 2002.
[8] W. Elmenreich H. Kopetz, W.Haidinger. Specification of the smart sensor interface. ResearchReport 7/2001, IST-1999-11585 Dependable Systems of Systems (DSoS), 2001. Available athttp://www.vmars.tuwien.ac.at.
[9] W. Haidinger and R. Huber. Generation and analysis of the codes for TTP/A fireworks bytes. ResearchReport 5/2000, Technische Universität Wien, Institut für Technische Informatik, Vienna, Austria, 2000.
[10] D. Hearn and M. P. Baker.Computer Graphics. Prentice Hall, 1986.
[11] C. Jones, M.-O. Killijian, H. Kopetz, E. Marsden, N. Moffat, D. Powell, B. Randell, A. Ro-manovsky, R. Stroud, and V. Issarny. Final version of the DSoS conceptual model.DSoS Project(IST-1999-11585) Deliverable CSDA1, October 2002. Available as Research Report 54/2002 athttp://www.vmars.tuwien.ac.at.
[12] H. Kopetz. Real-Time Systems, Design Principles for Distributed Embedded Applications. KluwerAcademic Publishers, Boston, Dordrecht, London, 1997.
[13] H. Kopetz, M. Holzmann, and W. Elmenreich. A universal smart transducer interface: TTP/A.Interna-tional Journal of Computer System Science& Engineering, 16(2):71–77, March 2001.
[14] H. Kopetz, M. Paulitsch, C. Jones, M.-O. Killijian, E. Marsden, N. Moffat, D. Powell, B. Randell,A. Romanovsky, and R. Stroud. Revised version of DSoS conceptual model.DSoS Project (IST-1999-11585) Deliverable IC1, October 2001.
[15] H. Kopetz et al. Specification of the TTP/A protocol. Technical report, Technische Universität Wien,Institut für Technische Informatik, Vienna, Austria, March 2000. Available at http://www.ttpforum.org.
[16] K. B. Lee and R. D. Schneeman. Internet-based distributed measurement and control applications.IEEEInstrumentation and Measurement Magazine, 2(2):23–27, June 1999.
[17] Motorola. MPC855T Users Manual Integrated Communications Microprocessor, April 2002. UsersManual. Available at http://www.motorola.com/semiconductors.
[18] N. Murphy. Principles of user interface design.Embedded Systems Programming, December 2000.
[19] Object Management Group (OMG).Smart Transducers Interface V1.0, January 2003. Specificationavailable at http://doc.omg.org/formal/2003-01-01 as document ptc/2002-10-02.
[20] PCMCIA. PC Card Standard 8.0. PCMCIA, 2001.
[21] P. Peti and L. Schneider. Implementation of the TTP/A slave protocol on the Atmel ATmega103 MCU.Technical Report 28/2000, Technische Universität Wien, Institut für Technische Informatik, Vienna,Austria, August 2000.
[22] Philips. SJA1000 Stand-alone CAN controller, August 1997. Product specification. Available athttp://www.philips.semiconductors.com.
[23] L. Schneider. Real time robot navigation with a smart transducer network. Master’s thesis, TechnischeUniversität Wien, Institut für Technische Informatik, Vienna, Austria, 2001.
[24] C. Trödhandl and L. Schneider. Interfaces for ttp/a intercluster communication and monitoring. ResearchReport 5/2002, Technische Universität Wien, Institut für Technische Informatik, Vienna, Austria, 2002.
Deliverable PCE4 61 Final Demonstration of Smart Sensor Interface