Transcript Mikrocentrum - Brand Innovators of Digital Products

Logo
A practical implementation of a data collection
and control system
A tour through a project which uses the BI-0501 to set
up a two way data and control connection between a
moving car and a fixed control center
The Agenda
•
•
•
•
•
Introduction to Brand Innovators
Project goals
Description of the BI-0501
Project implementation
Current status and improvements
Page 3
A Company Profile
• Headquartered in Nuenen, the Netherlands
• Products and Services
– Full-service provider of microcomputer hardware, software and
engineering support for real-time, open systems
– Primarily designs and manufactures VMEbus compatible boards
and single board computers, which are typically embedded in a
larger system
– Customers are primarily Original Equipment Manufacturers (OEMs)
Page 4
The Current Customer Situation
• Up to 200 newly developed prototype cars are driven around a
large test circuit
• Up to 800 human drivers are required to keep these cars on the
road for 24 hours a day and 7 days a week
Page 5
The Desired Customer Situation
• Cars are driven around the test circuit autonomously,so no
human drivers are required
• Each car is equipped with several CAN networks
• All messages on these CAN networks are to be send to a
control center to allow for real time monitoring and data storage
for further analyses
• Control messages are generated in the control center and are
submitted to the car to be delivered on the proper CAN channels
Page 6
The Participation of Brand Innovators
• Collect and package messages from eight independent CAN
networks and make them suitable for radio transmission
• No CAN messages should be lost
• Receive commands via a radio link and forward them to the
appropriate CAN networks
Page 7
The BI-0501 Fulfils the Project Requirements
• The BI-0501 hardware was readily available when the project
started
• The application software needed for the project is quickly
developed using the RTEMS kernel and the available low level
device drivers
• Consequently the BI-0501 was never time critical in this project
Page 8
A Description of the BI-0501
• The BI-0501 is a single board computer which connects up to 8
independent CAN networks to an office network
• It comes in a standard single height 19” rack mountable box
• It uses a single 24 Volt DC power supply
• It does its work quietly, no fans or ventilation openings are
needed
Page 9
The Available Interfaces
•
•
•
•
Up to eight CAN interfaces
An Ethernet interface both coax and twisted pair
An RS-232 interface with modem control signals
An RS-485 interface with direction control
Page 10
Available Processing Power and Memory
•
•
•
•
•
Motorola MC68EN360 @ 33MHz with optional MC68040
Static Random Access Memory (SRAM) - 512 kByte
FLASH memory - 2 MByte
Temperature measurement
Real Time Clock (RTC)
Page 11
The Embedded Software - Kernel
• Real Time Executive for Multiprocessor Systems
RTEMSTM
– Priority based, preemptive scheduling
– Rate-monotonic scheduling (i.e. hard real time)
– Common synchronization primitives
•
•
•
•
•
message passing
events
semaphores
signals
timers
• Low level drivers for hardware devices and interfaces
Page 12
The Embedded Software - TCP/IP Stack
• USNET ® Real-Time Networking Suite (RFC Compliant)
• Protocols
–
–
–
–
–
–
Page 13
TCP
UDP
IP
ICMP
ARP
RARP
- Transport Control Protocol
- User Datagram Protocol
- Internet Protocol
- Internet Control Message Protocol
- Address Resolution Protocol
- Reverse Address Resolution Protocol
The Development Software
•
•
•
•
FreeBSD is used as the Unix Development Host
GNU C Cross Compiler (gcc)
GNU Debugger (gdb)
The debugger is connected to the BI-0501 through a
Background Debug Mode (BDM) interface
• High level language Data Display Debugger (DDD) allows
source level debugging of the RTEMS tasks
Page 14
The Choice of Software Components
• All software components are C source level products
–
–
–
–
–
–
RTEMS Kernel
TCP/IP Stack
FreeBSD Host Environment
GNU C Cross compiler
Gdb Debugger
DDD Source Level Debugger
• There is no single piece of software running on the BI-0501 or
the FreeBSD system that is not available as source
Page 15
The Standards Being Adopted
• CAN - ISO/DIS 11898
• Ethernet - 802.3
– 10Base2
– 10Base-T
•
•
•
•
•
•
RS-232 - AT D9
RS-485 - Profibus
POSIX
IEEE 1149 Test Access Port and Boundary-Scan Architecture
TCP/IP (UDP, TCP, BOOTP)
HDLC
Page 16
Wireless Ethernet
• The original idea was to have Wireless Ethernet between the
car and the fixed station to build a connection between the car
and the control center
• The problem was that Wireless Ethernet (802.11) was not yet
available for long distances
BI-0501
Page 17
wire
less
wire
less
NT
Two Separate Channels
• A high frequency channel is used to send data from the car to
the control center, HDLC packets are transmitted through the
RS-485 link
• A lower frequency channel is used for sending commands from
the control center to the car, asynchronous packets are send
through the RS-232 link
• In this manner, a two way connection is established between the
car and the control center
BI-0501
Page 18
wire
less
wire
less
wire
less
wire
less
BI-0501
NT
The Ethernet Connection - UDP
• Fast transport without confirmation
– Received CAN messages are bundled into packets with a
maximum size of 256 bytes
– A HDLC protocol with Manchester bit encoding is used on the RS485 link
– Received HDLC packets are translated into UDP packets on the
Ethernet link
– The UDP mode connection has the advantage of less overhead
– The choice for UDP can be validated by the fact that the Ethernet
connection between BI-0501 and the NT system is less susceptible
to disturbances
Page 19
The Ethernet Connection - TCP
• Reliable transport with confirmation
– A TCP connection on the Ethernet link is used to send control CAN
messages (commands)
– Commands are translated into an asynchronous protocol on the
RS-232 link
– Every command given through the RS-232 link is confirmed
through the RS-485 link
Page 20
The Tasks Running - Moving Car
• INIT_Task:
– Initializes all hardware, starts up the three process tasks and
terminates itself
• HDLC_Task:
– Listens on eight CAN channels and relays incoming messages to
the RS-485 link
– Monitors temperature and sends it via the RS-485 link
• UART_Task
– Listens on RS-232 link for incoming commands and sends them to
the appropriate CAN channel
• ALIVE_Task
– Kicks the watchdog when HDLC_Task and UART_Task are still
alive
Page 21
The Tasks Running - Control Center
• INIT_Task:
– Initializes all hardware
– Uses the BOOTP protocol to get an IP address to enable
communication with Host NT system
– Starts up the three process tasks and terminates itself
• UDP_Task:
– Listens on RS-485 link and relays HDLC packets to Ethernet
• TCP_Task:
– Listens on Ethernet and relays commands to RS-232 link
• ALIVE_Task:
– Kicks the watchdog when UDP_Task and TCP_Task are still alive
Page 22
Losing CAN Messages
• CAN Messages could be lost
– due to CAN controller overruns during “bursts” of messages
– during radio transmission from car to control center
Page 23
The Overrun Problem on the CAN Controllers
• CAN messages can be received as fast as every 47 µs
• When we have to deal with this load on all eight CAN channels
at the same time then we receive a CAN message every 47 / 8
= 6 µs
• The processor will most likely not be able to handle this kind of
amount of data
• However, the average load on all CAN channels will generally
be much lower
• Added hardware can deal with occasional “bursts” of CAN
messages
• Processor only has to deal with the “average” loads
Page 24
The Overrun Solution - FPGA
• To deal with the occasionally “bursts”, each CAN interface is
accompanied with an extra FIFO device
• An proprietary FPGA transfers incoming CAN messages to the
FIFO devices for eight CAN controllers
• This added hardware guarantees that no CAN messages will be
lost during bursts
Page 25
The Overrun Solution - FIFO
• The FIFO size can be adjusted to the maximum length of the
bursts that should be tolerated, currently 16k FIFO devices are
installed
• Bursts lengths can be 16384 / 2 bytes * 47 µs = 385024 µs
bursts = 0.385 seconds before overruns are inevitable
• The bursts can actually last longer because the processor will
be continuously emptying the FIFO devices at the “average”
speed)
Page 26
Losing Data Packets During Transmission
• Atmospheric disturbances
• Reflection causing signal cancellation
• Signal blockage
– tunnels
– buildings
– fences
Page 27
The Possible Solutions to Prevent Data Loss
• Use Spread Spectrum to avoid cancellation
• Use smaller HDLC packets
• Use Forward Error Correction
– Reed-Solomon Codes
Page 28
Possible Solutions - Recorder
• Add separate data recorder in car
• Use Ethernet to connect to recorder
BI-0501
Recorder
Page 29
wire
less
wire
less
wire
less
wire
less
BI-0501
NT
Possible Solutions - High Level Protocol
• Use higher level protocol (TCP or PPP) to confirm data arrival
on NT
• Use internal memory of BI-0501 to store data for retries
• 32 MByte stores up to 256 seconds of messages
32 MByte
DRAM
BI-0501
Page 30
wire
less
wire
less
wire
less
wire
less
BI-0501
NT
The Current Status
• The project has reached the status that data collection is
guaranteed from the CAN networks to the BI-0501 due to the
use of the FPGA and the FIFO buffering
• However, because of the unreliable transmission over the 1Mbit
radio link, data loss is still possible
• Two solutions are under investigation
– use a higher layer protocol
– use a data storage in the car
• And, when time passed, the Wireless Ethernet technology has
evolved into a potential solution
• In all cases, the BI-0501 is capable of providing the necessary
interfaces and processing power to make these solutions viable
Page 31