CAN Application in Avionics

CAN application in avionics Final Report
Gruvgatan 8 S-421 30 Gteborg Sweden Authors: Anders Emrich
URL: www.omnisys.se Tel. +46 31 7096970 Fax. +46 31 7096979 Date: 11/07/01 Pages: 1 of 42
CAN application in avionics
Project: Reference: WP #: Prime Contr.: Contractor: Contact: Abstract:
CAN application in avionics Final Report ESTEC Omnisys Instruments AB Dr. Anders Emrich
This report look into various aspects of using the CAN-bus in the space environment. The main focus is on the electrcial interface and distribution, but some discussion regarding the high level protocol aspects is also included. Three implementations of the electrical interface are discussed and one of them has been evaluted with a hardware breadboard. Spice simulations has been performed for two of the implementations.. It seems quite clear that for a majority of applications, the ISO high speed, differential bus is to be prefered. If high voltage isolation, it is possible to consider local opto isolators without changing the rest of the system. For voltage isolation between several subsystems, but the distance being short, the transformer isolation could be considered, but it requires a non standard modulation on the bus.
Introduction............................................................................................................ 5
1.1 1.2 1.3 Overview........................................................................................................... 5 Basic Technical Description of Standard CAN............................................... 6 Suggestion on selection of bus type.................................................................... 6
Logical bus topology............................................................................................... 7

2.1 2.2 Number of buses................................................................................................ 7 Example: The SMART-1 type (early) ................................................................ 7
General Considerations for the use of CAN in space ........................................... 9

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 Availability of components ................................................................................ 9 Single point failure tolerance............................................................................. 9 Propagation of local fault .................................................................................. 9 Error rate.......................................................................................................... 9 Robustness to random radiation errors ............................................................. 9 Robustness to radiation..................................................................................... 9 Robustness to vibration..................................................................................... 9 Robustness to temperature ................................................................................ 9 Real time and hard real time ............................................................................10 Network length and number of nodes...............................................................10 CAN Silicon Solutions ......................................................................................10
Electrical Interface possibilites............................................................................ 11

4.1 4.2 4.3 Single and differential wire...............................................................................11 Galvanic Isolation ............................................................................................13 Electrical Topology ..........................................................................................16
Tranceiver Realisation examples......................................................................... 17

5.1 5.2 5.3 5.4 Discrete realisation of the ISO non galvanic interface ......................................17 Transformer isolated CAN interface ................................................................20 Standard ISO implementation based on TJA1050 ............................................24 Tranceiver Realisation Conclusions .................................................................28
System Redundancy.............................................................................................. 29
6.1 6.2 Cold Redundancy .............................................................................................29 Warm Redundancy ..........................................................................................31
Medium / High level protocol considerations ..................................................... 34

7.1 7.2 Mapping of ESA telemetry standard on CAN ..................................................34 CAN protocol suggestion..................................................................................35
System architecture example ............................................................................... 38
8.1 8.2 8.3 8.4 8.5 8.6
Introduction.....................................................................................................38 Basic assumption and preferences ....................................................................38 Essential Communication.................................................................................40 Payload Communication ..................................................................................40 System priority.................................................................................................40 Start-up ............................................................................................................41
9 10
References ............................................................................................................ 42 List of books and links...................................................................................... 42
List of Abbreviations
ASIC Application Specific Integrated Circuit CAN Controller Area Network ESA European Space Agency FPGA Field Programmable Gate Array ISO International Standard Organisation OBDH On Board Data Handling SMART-1 ESA satellite TBC To Be Confirmed TBD To Be Defined VHDL VHSIC Hardware Description Language UART Universal Asynchronous Receiver Transmitter WP Work Package WPD Work Package Description
1
1.1
Introduction
Overview
Modern satellites use either point to point communication or one of several buses for subsystem communication. The most common buses in use are:

MIL-STD-1553 or 1773 for most US satellites and some ESA satellites ESA OBDH on some ESA satellites
These communication buses have several drawbacks, the common ones are: Single master type (requires critical and awkward central planning, tricky to implement redundancy) High power consumption Costly development support Furthermore, in the case of OBDH there is virtually no hardware or software available today. An alternative to the MIL-STD-1553 and the ESA OBDH that could be considered is the adaption of a standard commercial bus for use in space. One such bus with proven reliability and with an abundance of development tools is the CAN-bus, currently being used in some 90 % of all new cars and the most common bus for modern industry automation projects. There are however two problems that must be solved when considering using the CAN-bus in space: 1: Availability of radiation tolerant chips, 2: Support for hardware redundancy. (1) can be solved by using modern FPGAs that now have enough complexity to support a complete CAN-controller, while a concept for (2) exist, originating from work performed during the SMART-1 phase B. MIL-STD-1553: HighRel type radiation hard components exist single master type of bus widely used in military systems and US space projects fair development support transformer coupled high power consumption.
OBDH bus: HighRel type radiation hard components exist single master type of bus only used in some ESA space projects limited development support transformer coupled medium power consumption
CAN-bus: Used in automotive and industrial applications multimaster type of bus no radiation tolerant components available but FPGA implementations possible excellent development support choice of physical implementation, opto coupler, transformer etc. very flexible very reliable (sent bit check, stuff bits, CRC etc.) Direct point to point interfaces complicated redundancy scheme
1.2
Basic Technical Description of Standard CAN

Robert Bosch GmbH designed the CAN protocol for use in automotive control networks. CAN offers fast, deterministic, prioritized performance with short messages and extensive error detection. With its low-cost components and built-in fault detection capability, this protocol is applied to a wide variety of nonautomotive applications. Adoption of this protocol by Allen-Bradley and Honeywell for their industrial control device networks has helped CAN gain world-wide acceptance. One reason for CANs success is its simplicity; CAN controllers can be thought of as advanced UARTs offering a basic set of efficient services. The system designer is free to design additional services to meet the application needs, optimizing as needed. CAN uses the binary countdown method to provide deterministic prioritized medium access. The medium has two states; a dominant and a recessive state where the dominan state wins out over the recessive. All nodes wait for the medium to become idle before transmitting a message. Each message begins with an arbitration field made of a unique message identifier. During the transmission of this identifier, each transmitting node compares the bus state with what it is attempting to send. If at any bit position the node detects a dominant bit while attempting to send a recessive bit, the node loses arbitration and aborts transmission. Therefore a node with a smallest identifier value wins the bus arbitration (a dominant bit is represented by a logical 0). Figure 4 shows an example of two nodes contending for the bus. Node 5 drops out during the third bit, after receiving a dominant signal while sending a recessive signal.
Figure 1. Bitwise medium arbitration
This medium access method is very efficient because no bandwidth is lost during arbitration. Bus throughput is high under both light and heavy traffic conditions, reaching 1,000 msgs/s at 125Kbps and 8,000 msgs/s at 1Mbps. CAN provides five error detection mechanisms, including a 15-bit cyclic redundancy check (CRC) code that detects nearly all potential message bit errors. The CAN protocol has its own limitations. Because CAN nodes must listen to the bus while transmitting, the bit length must be at least twice the propagation delay. Therefore, high speeds are only supported for short buses (500m for 125 Kbps, 100m for 500Kbps, and 50m for 1Mbps). Some applications require electrical isolation between the bus and nodes. Bit/s: Msgs/s: Package: Behavior: 100k-1M 8000 (at 1 Mbit/s) 8 bytes deterministic
1.3
Suggestion on selection of bus type

review off-the-shelf equipment to be used if most essential off-the-shelf use either 1553 or OBHD, use this for the essential bus, otherwise use CAN (or even direct access) for payload, use CAN (multimaster is much more flexible) Suggestion of implementation: Consider use of HUBs located together with Power Load Switches and share cabling, at least to Payload.
Logical bus topology

The overall logical bus topology, and the requirements needs to be considered for the evaluation of suitability of a particular bus type and implementation.
2.1
Number of buses
A very early question for the design of satellites is the type and number of buses to use for control and data read-out. It can happen that a decision is made to reduce this, even down to one bus, very early in the design process. The result from this is not only electrical, it also involves the overall project organisation, i.e. the organisation structure must reflect how many parties needs to be coordinated. Based on experience, at least two different buses should be considered, one essential and one for the payload. The reason is both organisational and physical. The essential subsystem is commonly pure industrial with its participants, i.e. formal specifications, test procedures etc. In addition, there is a lot of re-use from project to project in this area. By contrast, the payload is very often a new development for this project with no or very little previous experience. Furthermore, for science missions, it can be that a large fraction of the organisation can be from the university / research institute side with very limited organisation and qualification for a space project. The essential side can have more limited data transfer needs compared to the payload, however, the need for real-time response is obvious in most systems. The CAN-bus will meet the requirement for most essential systems. The payload requirements on the other hand will vary from mission to mission, but it is common that a lot of data is transferred to ground for further processing, or in the case of a communication satellite, there is a lot of data in both directions. It depends on the payload, but the CAN bus can meet the requirements for several types as the download bandwidth is often less the CAN bandwidth of some 500 kbit/s. The use may require the use of local buffers and/or a different system planning and layout.
2.2
Example: The SMART-1 type (early)

This example is based on very early discussions regarding the SMART-1 satellite and should not be confused by the real project. The idea is based on a three axis stabilised system incorporating electrical propulsion as well as scientific payload. The essential side has slightly more demands than a fixed satellite. One possible block solution is in Figure 2.
PWR CNT 1 hot+ 1 cold

16-bit CPU 64k RAM 8k+128k ROM
Earth Sens
Gyro CNT
Star tracker
Earth Sensor
CAN
X-band Tx Aux-CNT System CNT Memory

32-bit CPU 32M EDAC RAM 32 k ROM 1M EEPROM 0.5 GByte
Payload CNT Memory

32-bit CPU 32M EDAC RAM 3 2k ROM 1M EEPROM 0 .5 GByte
TM/TC
S-band Rx S-band Tx
Auxillary I/O
1 hot+ 1 cold
Passive CAN
3 indentical processor nodes 2 hot +1 cold
2 hot ? Active back-up 1 Mbit/s
Experiment A
Experiment B
Experiment C
Experiment D
Figure 2. SMART 1 satellite block level sketch for the control and communication planning
The system is quite straightforward with the major items being: Two logical buses, one for the essential side and one for the payload side Two system controllers, one is redundant Two payload controllers, one is redundant Two TM/TC units, connected two both buses Several subsystems on both buses Furthermore, on the low level electrical side, there is no very sensitive device for EMC on the TM/TC interface, nor any extreme high voltage subsystems (the Ion drive will have a few houndred volts). Furthermore, the satellite is quite small and the systems will not be separated with more than 0.1-2 meter. This means that there is no real requirement for galvanic isolation in this application, as long as the engineering is done right. If one or two intruments would really need isolation, and / or the rest of the satellite must be isolated from them, this could be solved with local isolation, not seen on system level.
3
3.1
General Considerations for the use of CAN in space

Availability of components
CAN components are presently being used in most new cars and in automated industry, which means that the components will continue to be developed and be available in the future. The standard devices continue to improve in terms of EMC, ESD and power consumption.
3.2
Single point failure tolerance

The use of two separate buses will make the system completely single point failure tolerant. If only one hub is used, the system is failure tolerant to a number of single point failures. There is a possibilty to have passive redundancy or active.
3.3
Propagation of local fault

A faulty node within a system can ruin the transmission of a whole system, e.g. by occupying all the available bandwidth. The CAN protocol has a built in feature that prevents a faulty node from blocking the system. A faulty node is eventually excluded from further sending on the CAN bus.
3.4
Error rate
The error handling of CAN is one of the really strong advantages of the protocol. The error detection mechanisms are extensive, and the fault confinement algorithms are well developed. The error handling and retransmission of the messages is done automatically by the CAN hardware.
3.5
Robustness to random radiation errors

As indicated above, the error handling of CAN is one of the really strong advantages of the protocol. Futhermore, if CAN controllers are implemented in FPGA's, you could reduce random radiation errors by standard design methods. However, the reduction of impact of random radiation errors could also be handled on highest system level, if needed.
3.6
Robustness to radiation
If an FPGA is used, there should be no problems with either SEL or total dose for most missions. An Actel SX32 for instance is SEL immune and tolerates 100 kRAD and a CAN cores consumes about 50-60 % of the device.
3.7
Robustness to vibration
The robustness to vibration is not very severe and should be comparable to the use of standard components, connector and cables. If the CAN controller is implemented in a FPGA, is will probably have a quite large package that dominates as the worst component. Special care will have to be taken when mounting the package, as with any other large component. The use of connectors and cables will not be more severe compared to other interconnects on the satellite as few conductors are needed. If a modern plastic package is used, the potential vibration problems more or less disappears for the devices.
3.8
Robustness to temperature
A majority of commercial CAN components (controllers, transceivers) have operational temperature ranges between +125 C and -40 C which is within satisfactory limits for space applications.
3.9
Real time and hard real time

Due to the priority system used in the CAN protocol, it is possible to ensure low individual latency times in real-time systems, even during times of overload.
3.10
Network length and number of nodes

The number of nodes that can be connected to a Controller Area Network is in theory only limited by the number of unique identifiers available (normal CAN offers 2032 identifiers, extended CAN 536870912). In practice however the driving capabilities of the transceiver circuits limits this. A normal number of nodes that can be attached to a single bus is between 32 and 64. Philips PCA82C250/251 allows for at least 110 nodes to be connected to a single CAN network. At a speed of 1 Mbit/s, a maximum cable length of about 40 meters can be used. This is because the arbitration scheme requires that the wave front of the signal can propagate to the most remote node and back again before the bit is sampled. In other words, the cable length is restricted by the speed of light. Other maximum cable lengths are: 100 meters at 500 kbit/s 200 meters at 250 kbit/s 500 meters at 125 kbit/s kilometers at 10 kbit/s
3.11
CAN Silicon Solutions

Almost every major silicon manufacturer (Philips, Intel, Motorola. Texas Instruments, Siemens, etc.) provides CAN chip solutions as standard product. Controllers: ex. Philips SJA1000, stand alone Intel 82527, stand alone
Transceivers: ex. Philips PCA82C251 CAN controller interface Philips TJA1050 CAN controller interface Alcatel MTC-3054 CAN interface Motorola MC33388 interface The Philips TJA1050 is a successor to the PCA82C250 transceiver. The TJA1050 has a high Electromagnetic Immunity (EMI) due to a receiver with a wide common-mode range and a significantly lower Electromagnetic Emission (EME) due to optimal matching of the CANH and CANL output signals.
Electrical Interface possibilites

In the paragraphs below, a general overview of different possible electrical realisations of the CAN bus is shown. This is complemented with more detailed schematics, simulations and protection description, one based on the ISO non galvanic specification, and one a galvanic transformer isolated implementation. It should be noted that latter one must use a "non standard" bit modulation technique. Other possible transmission media, not treated below, are IR and current carrier transmission. There have been special applications and experiments using these methods but no widespread general use, as there are several limitations.
4.1
Single and differential wire

The basic operation allows the CAN bus to work with a single wire, however it is not widely used, nor supported as a physical interface in the ISO11898 standard. It can be considered as a local alternative within a physical unit or for a very short distance. The ISO11898 standard incorporates one physical implementation using a differential line, similar to the RS-485 type. It is possible to use this as well for space use. In and Ref 2, the general bus structure is described. The ISO11898 standard allows for unshielded or shielded wiring. The wire chosen shall in compliance with the ISO11898.
Figure 3. Differential wire bus structure
There exist several possibilities when using the differential wiring, the obvious ones being to use: complete standard ISO11898 commercial transcievers use Space standard RS-485 transcievers, but connected is a special way, i.e. with TX controlling the Enable function etc, as indicated in Figure 3.1.
VCC
D3 1N5822 R1 4.75k C1 U1 C11 TBJD685K050C VCC GND 1 1 2
TX
3
0.1uF R5 47.5k
EN1 EN2
GND GND 6 7
CANLA R7 150R CANHA
2 4
D1 1N4148UR-1 RX R2 4.75k
GND 1
Figure 4. CAN tranceiver coupling of RS-485 device, the DS16F95J/883.
The choice between the two should be selected on project basis, and as long as the commercial devices are not susceptible to Single Event Latchup, we see no reason why not using standard commercial devices as these are better in terms of EMC
and are tougher in terms of overvoltage, apart from being used in multibillion dollar applications. As an exemple, Philips has introduced a transciever based on SOI, which should make it excellent in radiation terms.
Figure 5. Standard CAN architecture
As can be seen in Figure 5, the use of standard transcievers simplifies the electronics quite a bit, but it is also possible to meet IOS11898 with discrete solutions, as indicated in Figure 6.
Figure 6. The ISO11898 standard High Speed Medium Access Unit
The ISO 11898 standard states that the network terminating resistors used shall have a nominal value of 120 , a maximum value of 130 , and a minimum value of 118 . This termination prevents reflected waves on the bus lines and helps drive the differential voltage to ~0V during the transmission of recessive bits on the bus. Every node should be fitted with filtering resistors on the input to prevent reflected waves being superimposed on the signal due to the internal impedance of the bus transmission lines and the stub connecting the node to the bus wires.
The use of standard devices is still recommended, if formal ESA space standards are put aside. Some devices are listed in Table 1.
Table 1. Examples of CAN transceivers on the market
It is possible that with a large number of devices on a CAN bus, buffering would be needed and one solution with a repeater is shown in Figure 7.
Figure 7. Block diagram drawing of CAN bus repeater
A repeater is a device that electrically buffers two bus sections from each other, allowing more CAN nodes to be connected to one bus. On the other hand, the use of repeaters limits the maximum baudrate and/or the maximum physical bus length, since they introduce a delay between each bus section. However, it is strongly advised by Omnisys to look again at the complete system design again, it seems likely this should be solved on a higher level.
4.2
Galvanic Isolation
Galvanic isolation of electrical units in a system is used to eliminate internal ground loops, increase the noise immunity of a system, reduce effects of electrical noise, and protect equipment and user should the unit or something in its surroundings malfunction. Isolation is also an important way to prevent static and most kinds of damaging surges in data communications systems.
4.2.1 No Isolation
With no isolation the units on the CAN network is directly connected to the busline, and it is difficult to prevent the propagation of ground loops, transients, and other disturbances in the system. The resulting reduction in components when opting for a non-isolated system in a satellite with a large network reduces overall spacecraft cost and mass in a not insignificant way.
The non isolated interface is also the most widely used, which is a very strong argument, both for access to robust devices, but also for design, testing and verification.
4.2.2 Optic Isolation

Optic isolation is commonly used when galvanic isolation is required. However, the use of optic isolators in space requires extra thinking and consideration. Optic isolators are energy detectors and thus susceptible to both radiation single event effects and total dose. Optic isolation of circuitry is not supported by the ISO11898 standard.
Figure 8. Galvanic isolation using opto couplers
Fibre optics are inherently immune to electrical and magnetic interference, and the integration cost due to interference and cross-talk discovered during integration is virtually zero. Additional benefits of using fiber optics are weight reduction due to decreased electrical wire usage, and increased data rate capabilities. To this date it is however unknown how radiation will affect the optic fibre (darkening etc) when exposed to radiation during a deep-space mission. Due to the relatively recent development of fibre applications suitable for space there is a limited number of mature procedures and flight-qualified components available.
Figure 9. Opto couplers on all nodes
In Figure 9, a design is indicated with optocouplers on all nodes in the system. This would add a not insignificant number of devices with potential radiation problems, from SEU, SEL to total dose effects.
Figure 10. Opto couplers only when needed
In figure 10, the solution with a few opto couplers is indicated, which is prefered and should only be used when absolutly necessary. If the opto coupler missbehaves, it is possible to shut the complete device down and still operate the bus, i.e. the need for the isolation is device specific and device solved.
4.2.3 Transformer Isolation (bi-phase modulation)

This is supported by very early CAN-circuits but not used to any extend. The units on the network are protected by a transformer that effectivly shields the units from unwanted noise and potentially dangerous disturbances. The use of a NRZ signalling scheme in CAN introduces a problem when using transformer isolation in a circuit. A transformer in which a signal of one and the same level is transmitted builds an magnetic flux in the core. This field can only reach a set value before the core suffers a breakdown and effectively short circuits the primary and secondary windings of the transformer. To prevent the electric field from reaching this level in case a long stream of 1s or 0s is transmitted, the transformer can be reset by transmitting a signal of opposite polarity (AC signalling) or by letting it reset by itself by dissipation of the electric field over a period of time. The latter method is obviously not applicable when dealing with bit rates of 1 Mb/s. The active resetting can be achieved both in software solutions and discrete hardware solutions.
4.3
Electrical Topology
The number of nodes that can be connected to a Controller Area Network is in theory only limited by the number of unique identifiers available (normal CAN offers 2032 identifiers, full CAN offers 536870912). In practice however the driving capabilities of the transceiver circuits limits this. A normal number of nodes that can be attached to a single bus is between 32 and 64. Philips PCA82C250/251 allows for at least 110 nodes to be connected to a single CAN network.
4.3.1 ISO 11898 solution

The ISO 11898 dictates that the topology of the CAN network should be as close as possible to a single line structure (this to avoid reflected waves). In practice short stubs are used to connect the different units to the bus line. The CAN protocol is developed with such a topology in mind.
4.3.2 Hub based topology

There is an alternative that could potentially increase the integrity of the bus, but most of all it would simplify the system integration and test and that is to use a central hub and where each subsystem is connected to it and not to the other units. The CAN protocol does not inherently support this kind of topology.
Figure 11. Block level drawing of a hub based realization of the CAN bus
5
5.1
Tranceiver Realisation examples

Discrete realisation of the ISO non galvanic interface
The task is to design a non isolated CAN tranceiver, complient with the ISO specification, based on available HiRel components. There exist alternatives for all components, but the types shown and listed should be available. A suggested design is shown in Figure 12, which also includes protection against producing overvoltage on the bus.
Vcc R1 1k Vcc C1 10n Q1 2N5771
D2 BAS40 R10 Tx 4.7k Q4 2N2369 R11 330
R12 4.7
D4 CAN high BAS40
D3 BAS40
R13 4.7 Q5 2N2369
D5 CAN low BAS40
R3 1k
R7 27k
R8 27k
Vcc Vcc R4 1k Rx U1A LM193 Vcc C3 R19 2.7k
Vcc R21 2.7k
10n
R18 150k
R20 2.7k
R22 2.7k
R17 470k
Figure 12. Non isolated CAN tranceiver design.
Design details: The delay in/out of the drivers is determined by the selection of both the bipolar transistors and by the comparators used in the receivers. The selected devices in the schematics shown in Figure 12 allows for 1 Mbit/s transmission and more than 30 nodes. Transmitter delay: Receiver delay: Output impedance: Input impedance: Transmitter level: Receiver threshold: 30ns 70ns 10ohm 56kohm 2.7V 400mV 120mV
Because of the nature of the CAN bus, where dominant bits are driven actively and recessive bits are not, the recessive bits will always cause more transmitter/receiver delays than dominant bits. The figures given for the transceiver delays are worst case, i.e. those for dominant to recessive transition. One of the most critical aspects in most systems, if based on two redundant buses, would be to protect the system from different types of power supply faults, triggered by the tranciever. In figure 13, a safe tranceiver supply is shown, protected against overvoltage and with current limitation.
U12V R1 47k R4 27k R5 1k R9 30
Q1 2N2907ACSM
Q2 2N2907ACSM
D3 1N5314
Q3 2N2222ACSM D1 1N4626 R2 470k R3 470k
Vcc
Q5 2N2222ACSM Q4 2N2222ACSM D2 1N4626 C4 10n D4 1N5968 C3 100n
R12 10k GND
Figure 13. Power supply for the tranceiver.
5.1.1 Transmission line simulations

We have selected to present three simulations:
12.0 18.0 1 12.0 18.0 1 12.0 1 18.0
8.00
UREC in Volts
14.0
8.00 2
UREC in Volts
14.0
8.00 2
UREC in Volts
14.0
4.00
10.00
4.00 3
10.00
4.00 3
10.00 3 6.00 4
6.00 4
6.00 4
-4.00
2.00
-4.00
2.00
-4.00
2.00
500N
1.50U
2.50U
3.50U
4.50U
500N
1.50U
2.50U
3.50U
4.50U
500N
1.50U
2.50U
3.50U
4.50U
WFM.4 UREC vs. TIME in Secs
Figure 14. Simulation with the three different set-ups: 5 m cable with nominal termination, 30 m cable with nominal termination and cable with 80 ohm instead of 120 ohm termination. The top trace show driver input signal, the second the driver output signal, the third the receiver input signal, and the last, the receiver output signal.
The result is shown in Figure 14, that indicates that even with 30 m cable length and with "faulty" termination, the signal transmission is perfect after reception.
5.1.2 Common mode simulations

The common mode rejection simulation is relevant for non isolated designs. Depending on overall electrical design of a satellite, different problems and levels could be expected. With a reasonalble size satellite, lets say maximum distance of 2 m, and good electrical design, only a couple of volts can be expected in common mode difference between nodes. The result from simulations shows common rejection from -11 V to +34 V, which should be sufficient for almost all applications.
5.1.3 RF noise susceptibility
10.00
18.0
10.00
18.0
10.00
18.0
14.0
1 0
14.0
1 0
14.0
UREC in Volts
UREC in Volts
-10.00
10.00
-10.00
10.00
UREC in Volts
-10.00
10.00
-20.0
6.00
-20.0
6.00
-20.0
6.00
-30.0
2.00
-30.0 2 500N 1.50U 2.50U 3.50U 4.50U
2.00
-30.0 2 500N 1.50U 2.50U 3.50U 4.50U
2.00 2 500N 1.50U 2.50U 3.50U 4.50U
Figure 15. Noise with 100kHz, 1 MHz and 10 MHz, 10 V rms applied. No sensitivity can be seen.
The simulation show no design problems with RF susceptibility, but this should be complemented with real world testing for a particular implementation, is it is dependent to a large degree on cable and connector imperfections.
5.1.4 Availability
There should be no problems in availability of suitable components, all components used are available in MIL883 and or QMLQ and most could be attained with at QMLV, if so required. However, with lead time etc., it could be smart to change type on the diodes and transistors, there exist similar devices that could be easier to optain for a specific project.
5.1.5 Single point failure tolerance

The use of two separate buses will make the system completely single point failure tolerant. There is a possibilty to have passive redundancy or active.
5.1.6 Propagation of local fault

A faulty node within a system can ruin the transmission of a whole system, e.g. by occupying all the available bandwidth. This could be handled in various ways, but is a system level question, i.e. not only related to the bus tranceiver.
5.1.7 Error rate

5.1.8 Robustness to radiation

More of a matter for the control device, but it shoul be noted that the error checking in the CAN protocoll is very strong, and random errors should only result in retransmission of one CAN package. With the design shown, there should be no problems with either SEL or total dose for most missions, at least 30-100 kRAD total dose tolerance could be expected, depending on components used.
5.1.9 Robustness to vibration and temperature

The robustness to vibration is not very severe and should be comparable to the use of standard components, connector and cables. There should be no difference compared to other electronic circuits as the same type of components is used.
5.2
Transformer isolated CAN interface

In contrast to the normal output mode the bit representation is time variant and toggled. If the bus controllers are galvanically decoupled from the bus line by a transformer, the bit stream is not allowed to contain a DC component. This is achieved by the following scheme. During recessive bits all outputs are deactivated (floating), indicated in Figure 21 by grey areas. Dominant bits are sent with alternating levels on TX0 and TX1, i.e. the first dominant bit is sent on TX0, the second is sent on TX1, and the third one is sent on TX0 again, and so on. One possible configuration example of the biphase output mode timing is shown in Fig.16.
Figure 16. Bi-phase modulation.
A transformer isolated CAN tranceiver design is shown in Figure 17, and TX0/TX1 is used as indicated in Figure 16. It is based on discrete components and there should be no availability problems. The design is based on a standard transformer design, but this must be ordered as a custom product, depending on both real physical aspects, such as size, and on formal quality aspects used for a particular project. Transmitter delay: Receiver delay: Output impedance: Input impedance: Transmitter level: Receiver threshold: 60ns 70ns 10ohm 35kohm +/- 4V 3.15V 20mV
Because of the nature of the CAN bus, where dominant bits are driven actively and recessive bits are not, the recessive bits will always cause more transmitter/receiver delays than dominant bits. The figures given for the transceiver delays are worst case, i.e. those for dominant to recessive transition.

Vcc Vcc R20 1k Vcc C4 10n R18 2.2k R16 22k Vcc
Rx U1A LM193 R17 2.2k R19 1M R15 27k R14 22k
C3 100n
Vcc
D7 R12 10 D5 BAS40 Q7 BC817 Q8 BC817 R9 D6 BAS40 BAS40 R13 10 D8 BAS40
L1 TRANS_1_2
R8 1k Tx0
Tx1 1k R10 1.5k R11 1.5k
Figure 17. Transformer isolated CAN tranceiver design.
One of the most critical aspects in most systems, if based on two redundant buses, would be to protect the system from different types of power supply faults, triggered by the tranciever. In figure 18, a safe tranceiver supply is shown, protected against overvoltage and with current limitation.
U12V R1 47k R5 27k R6 1k R7 30
Q1 2N2907ACSM
Q2 2N2907ACSM
D3 1N5314
Q3 2N2222ACSM D1 1N4626 R2 470k R3 470k
Vcc
Q5 2N2222ACSM Q4 2N2222ACSM D2 1N4626 C1 10n D4 1N5968
R4 10k GND
Figure 18. Power supply for the tranceiver.
5.2.1 Transmission line simulations

We have selected to present three simulations:
1 30.0 42.0 30.0 42.0 1
1 30.0 42.0
20.0
CANTERM in Volts URXT in Volts
32.0 2
CANTERM in Volts
20.0
URXT in Volts
32.0 2
CANTERM in Volts
20.0
URXT in Volts
32.0 2
10.00
22.0 3
10.00
22.0 3
10.00
22.0 3
12.0 4 5
12.0 4 5
12.0 4 5
-10.00
2.00
-10.00
2.00
-10.00
2.00
1.00U
3.00U
5.00U
7.00U
9.00U
1.00U
3.00U
5.00U
7.00U
9.00U
1.00U
3.00U
5.00U
7.00U
9.00U
WFM.5 URXT vs. TIME in Secs
Figure 19. Simulation with three different set-ups: 5 m cable with nominal termination, 30 m cable with nominal termination and cable with 80 ohm instead of 120 ohm termination. The top two traces show driver input signals, the third the driver output signal, the fourth, the receiver input signal and the last, the detected signal.
The result is shown in Figure 19, that indicates that even with 30 m cable length and with "faulty" termination, the signal transmission is perfect after reception.
5.2.2 RF noise susceptibility

The RF noise susceptibility simulation set-up is shown in Figure 20 .
6.00 4.00 4.00 6.00 4.00 6.00
4.00
2.00
2.00
4.00
2.00
4.00
URXT in Volts
URXT in Volts
2.00
2.00
URXT in Volts
URX in Volts
URX in Volts
URX in Volts
2.00
-2.00
-2.00
-2.00
-2.00
-4.00
-4.00
-2.00
-4.00
-2.00
10.00U
30.0U
50.0U
70.0U
90.0U
1.00U
3.00U
5.00U
7.00U
9.00U
1.10U
1.30U
1.50U
1.70U
1.90U
WFM.2 URX vs. TIME in Secs
Figure 20. Noise with 100kHz, 1 MHz and 10 MHz, 10 V rms applied. No sensitivity can be seen.
The simulation show no design problems with RF susceptibility, but this should be complemented with real world testing for a particular implementation, is it is dependent to a large degree on cable and connector imperfections.
5.2.3 Availability
For the transformer, this must be ordered separately from a qualified source, but for the other components, there should be no problems in availability, all components used are available in MIL883 and or QMLQ and most could be attained with at QMLV, if so required. However, with lead time etc., it could be smart to change type on the diodes and transistors, there exist similar devices that could be easier to optain for a specific project

The use of two separate buses will make the system completely single point failure tolerant. There is a possibilty to have passive redundancy or active.

A faulty node within a system can ruin the transmission of a whole system, e.g. by occupying all the available bandwidth. This could be handled in various ways, but is a system level question, i.e. not only related to the bus tranceiver.
5.2.6 Error rate


More of a matter for the control device, but it shoul be noted that the error checking in the CAN protocoll is very strong, and random errors should only result in retransmission of one CAN package. With the design shown, there should be no problems with either SEL or total dose for most missions, at least 30-100 kRAD total dose tolerance could be expected, depending on components used.

The robustness to vibration is not very severe and should be comparable to the use of standard components, connector and cables. There should be no difference compared to other electronic circuits as the same type of components is used.
5.3
Standard ISO implementation based on TJA1050

The TJA1050 is the successor to the PCA82C250 high-speed CAN transceiver. The most important improvements are: Much lower electromagnetic emission due to optimal matching of the output signals CANH and CANL Improved behaviour in case of an unpowered node (unpowered modes supported by other devices as well) Features Fully compatible with the "ISO 11898" standard High speed (up to 1 Mbaud) Very low ElectroMagnetic Emission (EME) Differential receiver with wide common-mode range for high ElectroMagnetic Immunity (EMI) An unpowered node does not disturb the bus lines Transmit Data (TXD) dominant time-out function Silent mode in which the transmitter is disabled Bus pins protected against transients in an automotive environment Input levels compatible with 3.3 V devices Thermally protected Short-circuit proof to supply voltage and ground At least 110 nodes can be connected.
5.3.1 BCD/SOI technology

From Philips: Philips Semiconductors' first SOI Smart Power process technology is called ABCD1 (Advanced Bipolar-CMOS-DMOS) - a single-poly, double-metal technology targeted for 12 V to 60 V applications - combining bipolar, CMOS and DMOS. The technology uses a 1.5 m active silicon layer on top of a 1 m layer of buried oxide. The oxide layer allows for complete isolation of all components formed on the chip and offers four key advantages as a result: reduced resistance when its transistors are in the on-state the absence of junctions between N- and P-type devices and the substrate much greater packing densities can be achieved parasitic capacitances are significantly reduced
These four factors lead to numerous advantages. Firstly, by decreasing the resistance Rds (on) by up to 20 %, A-BCD1 generates far less heat than equivalent bulk silicon processes, reducing or eliminating the need for heat sinks and keeping costs down. And with this low Rds (on) , SOI gives DMOS transistors excellent power handling capabilities, allowing designers to choose for the same size of chip of lower heat dissipation, or higher current handling ability, or a smaller chip with the same dissipation. The end result of this choise has, in one example, allowed stand-by power consumption to be reduced. Secondly, with no junctions between the n- and p-type devices and the substrate, SOI is intrinsically free from latch-up (associated with the overloading of bulk silicon transistors) and virtually eliminates problems arising from cross-talk via the substrate, load dump and other accidental high external voltages. These features make SOI inherently reliable and also allow for easy integration of multiple power devices, bridge rectifiers and flyback diodes on the same piece of silicon. When combined with CMOS, Bipolar, JFET and DMOS SOI devices, these advantages enable the creation of real smart power circuits.
Thirdly, the packing densities achieved by SOI represent a major advance on bulk silicon, enabling size reductions of up to 30 %: next generation A-BCD2 (EZ-HV) devices should be able to improve on this still further, as well as offering even lower Rds (on). Lastly, many of SOI's advantages come from the isolation of the components in the oxide layer, ensuring excellent insulation and, as a result, a significant reduction in parasitic capacitances, leading to quicker and easier design-in. Eliminating latch-up and parasitics provides other benefits as well, such as protection from voltage spikes. Because A-BCD1 does not need reverse-biased junctions to isolate components, leakage currents are avoided and so SOI has much greater heat tolerance, up to 160 C instead of the normal 125 C for bulk silicon. Comments from Omnisys: The use of SOI technology should remove two of the radiation problems of integrated circuits, the Total Dose degradation and the Single Event Latch-up, but this should be verified by either analyses or test. Furthermore, the probability of other types of single event faults should be reduced. As Philips is likely not to share information about their process, testing will be needed in that case.
5.3.2 Availability
Volume production is now running. Philips have some 80 % of the market share for CAN bus tranceivers (Anders Lundquist, Mecel, verbal communication), and while most systems now are based on "older" devices most new projects are designed around the TJA1050. The TJA1050 is available in plastic SO-8 in commercial and automotiv grade, and as tested but not screened naked die. Minimum, quoted volume, is 1000 devices for packaged devices and 2000 for naked die (Promax). The packaged devices should be available with smaller miminum volume shortly through other distributors. The cost is about 1 ECU per device, naked as well as packaged.

A current-limiting circuit protects the transmitter output stage from damage caused by accidental short-circuit to either positive or negative supply voltage, although power dissipation increases during this fault condition. A thermal protection circuit protects the IC from damage by switching off the transmitter if the junction temperature exceeds a value of approximately 165 C. Because the transmitter dissipates most of the power, the power dissipation and temperature of the IC is reduced. All other IC functions continue to operate. The transmitter off-state resets when pin TXD goes HIGH. The thermal protection circuit is particularly needed when a bus line short-circuits. The pins CANH and CANL are protected from automotive electrical transients (according to ISO 7637). The use of two separate buses will make the system completely single point failure tolerant. The tranceiver "bus off" mode can help in the implementation of different redundant schemes as well as the high impedance when in power down mode. In the silent mode, the transmitter is disabled. All other IC functions continue to operate. The silent mode is selected by connecting pin S to VCC. This mode can be
used by nodes that don't need to send any data, but can also be used to prevent network communication from being blocked etc,

A faulty node within a system can ruin the transmission of a whole system, e.g. by occupying all the available bandwidth. The TJA1050 incorporate some protection against completely faulty CAN messages through a timer, checking that the node is not stuck on Dominant. A TXD dominant time-out timer circuit prevents the bus lines being driven to a permanent dominant state (blocking all network communication) if pin TXD is forced permanently LOW by a hardware and/or software application failure. The timer is triggered by a negative edge on pin TXD. If the duration of the LOWlevel on pin TXD exceeds the internal timer value, the transmitter is disabled, driving the bus into a recessive state. The timer is reset by a positive edge on pin TXD.
5.3.5 Error rate and robustness to random radiation errors

As indicated in 4.8, the error handling of CAN is one of the really strong advantages of the protocol. The TJA1050 has also improved electrical behavior in several areas that reduce the error rate, such as 20 dB improvement in EMC, wider commen mode range and perhaps most importanly, the use of SOI technology should reduce the probability of single event errors induced by radiation, but this should be verified.

If an TJA1050 is used, because of the SOI technology, there should be no problems with either SEL or total dose for most missions.

The robustness to vibration is not very severe and should be comparable to the use of standard components, connector and cables. If a modern plastic package is used, the potential vibration problems more or less disappears for the devices. A majority of commercial CAN components (controllers, transceivers) have operational temperature ranges between +125 C and -40 C which is within satisfactory limits for space applications. This also applies to the TJA1050
5.3.8 Network length and number of nodes

The TJA1050 can be used with up to 110 nodes. The network length is dependent both on cable type and number of nodes, but the use of TJA1050 should match or improve on existing designs. The number of nodes, which can be connected to a bus, depends on the minimum load resistance a transceiver is able to drive. The TJA1050 transceiver provides an output drive capability down to a minimum load of RL.min = 45W for VCC > 4.75V. The overall bus load is defined by the termination resistance RT, the bus line resistance RW and the transceivers differential input resistance Rdiff. With RT of 118 ohm, this gives 131 nodes, and with RT of 130 ohm, this gives 170 nodes. The maximum achievable bus line length in a CAN network is determined essentially by the following physical effects:
1. The loop delays of the connected bus nodes (CAN controller, transceiver etc.) and the delay of the bus line 2. The relative oscillator tolerance between nodes 3. The signal amplitude drop due to the series resistance of the bus cable and the input resistance of bus nodes. Effects 1 and 2 determine a value for the maximum bus line length with respect to the CAN bit timing. Effect 3, on the other side, determines a value with respect to the output signal drop along the bus line. The minimum of the two values has to be taken as the actual maximum allowable bus line length. As the signal drop is only significant for very long lengths, effect 3 can often be neglected for high data rates. A data rate of 500 kbit/s gives a maximum length of 107 m. The calculation is based on effects 1 and 2 assuming an oscillator tolerance of better than 0.15%. Notice that the stated values apply only for a well terminated linear topology. Bad signal quality because of improper termination can lower the maximum allowable bus length. For most satellite applications, 1 Mbit data rate should not be any problem, as the most often better crystals are used and 30 m cabling would be considered very long.
5.3.9 Other aspects

Transmission lines must be terminated with the characteristic line impedance, otherwise signal reflections will occur on the bus causing significant ringing. The topology has to be chosen such that reflections will be minimized. Often the topology is a trade-off between reflections and wiring constraints. CAN is well prepared to deal with reflection ringing due to some useful protocol implementations: 1. Only recessive to dominant transitions are used for resynchronization. 2. Resynchronization is allowed only once between two sample points, and only if a recessive bit was sampled. The sample point is programmable to be close to the end of the bit time.
5.4
Tranceiver Realisation Conclusions

The CAN protocol has been around for close to fifteen years, and although it was designed for automotive applications (which still is the main area of use for CAN), the CAN protocol has been widely accepted in many industrial non-automotive applications as well. This is much thanks to its low cost, high performance, and the availability of various CAN-protocol implementations. The CAN protocol has four major benefits. (1), A standard communications protocol simplifies and economizes the interfacing of user subsystems onto a shared network. (2) The work load is shifted from the host-CPU to an intelligent peripheral; which leaves the host-CPU with more time to run its essential system tasks. (3) As a multiplexed network, a CAN-bus greatly reduces wire harness size and eliminates point-to-point wiring. (4) CAN has broad market appeal, and this motivates semiconductor developers to design competitively priced CAN chips. Using COTS in space is desirable, as the use of commercial components greatly reduces the cost and procurement time during a project. CAN was primarily developed for the use in cars, and this further supports the idea of using CAN components in space applications. This as the electrical and noise environment in a car is by far much harsher than that of a satellite. After studying the existing solutions for the CAN-bus, a differential signalling scheme on a standard bus structure in compliance with the ISO11898 standard is suggested for satellite applications. The ISO11898 leaves the choice of galvanic isolation undefined, but the use of transformer isolation to prevent the propagation of earth loops, transients, and other disturbances in the system is a possibilty that could be considered. The use of other designs, such as a hubbed bus topology or optic isolation should however not be completely discarded as there might be situations where this might be suitable.
5.4.1 Proposal A: non galvanic isolation

We strongly propose to use the ISO11898 standard with commercial transcievers. There is a multibillion dollar industri to back this up. This means that there is a vast access to devices, development systems, tools etc. but also to skilled engineers.
5.4.2 Proposal B2: galvanic isolation

If needed, and if all nodes need isolation, you could consider transformer isolation of the nodes.
System Redundancy
One important aspect is different redundancy concepts for the bus hardware. We discuss two concepts; warm and cold redundancy setup operates, both with majority voting. One alternative is described each for the cold and warm redundancy, several options exist in both cases, but this can be useful as examples.
6.1
Cold Redundancy
The basic system idea: Single CAN core in each node

Dual transceivers in each node Watchdog in each node, possible to override from local CPU Watchdog is reset through special CAN message When the watchdog times out, the CAN node toggles to the other transceiver. Watchdog times out after one time unit
PWR:A PWR:B PWR:C TC:A TC:B TM:A TM:B
CPU:A
CPU:B
CPU:C
Figure 21. System bus overview. Logical Bus only.
Start-up Sequence

Possible TC on The PWR units power up CPU:A Waits for CPU:A OK, 10 time units CPU:A tries bus A 5 time units, bus B 5 time units The PWR units shuts down CPU:A, powers up CPU:B CPU:B tries bus A 5 time units, bus B 5 time units Cycle can continue, i.e. A-B-C, send TC, A-B-C etc. If CPU:X starts, it transmits Watchdog Reset signal on the established bus CPU:X sends PWR ON commands to PWR:A,B,C for the different subsystems
When the Master CPU has turned on the sub-systems, it checks the operation of each device, for example demanding I am OK for each within a certain period of time. If any device does not respond, the Master CPU can decide to try establishing contact on the redundant bus. After the initial check the Master CPU can relinquish bus monitoring to the individual nodes by transmitting a periodical Watchdog Reset signal to every node on the established bus. The bus communication can fail due to either a physical problem (such as a break, or by a bus wire short to either ground or supply voltage), however a bus switch might also be recommended if failures of for example the CAN transceivers located in one of the nodes occur. Bus Failure 1 1. CPU:X stops transmitting Watchdog Reset signal to PWR:ABC on BUS:X due to failure of CAN transceiver or CAN controller. 2. The system goes to start-up again (see Start-up Sequence). Bus Failure 2 1. BUS:X is broken between CPU:X and PWR:ABC 2. The Watchdog Reset signal is lost and the system goes to start-up again. Communication will be established on non-broken bus Bus Failure 3 1. BUS:X is broken between CPU:X and TC:A 2. Watchdog Reset signal is lost and TC:A starts toggling between buses, TC:B can possibly still be used 3. Master CPU is monitoring BUS:Y and detects traffic. 4. Master CPU transfers TC:A back to BUS:X to make sure the transfer not was provoked by a transient problem, either by not transmitting a Watchdog Reset signal on BUS:Y or by transmitting a forcing CAN message. 5. If Master CPU decides to switch bus, the Watchdog Reset signal on BUS:X is terminated and transferred to BUS:Y. 6. All sub-systems will establish contact with BUS:Y. Bus Failure 4 1. 2. 3. 4. BUS:X is broken between CPU:X and Node:X. The Watchdog Reset signal is lost and Node:X toggles to BUS:Y Master CPU detects traffic on BUS:Y Master CPU transfers Node:X back to BUS:X to make sure the transfer not was provoked by a transient problem. 5. If Master CPU decides to switch bus, the Watchdog Reset signal on BUS:X is terminated and transferred to BUS:Y. 6. All sub-systems will establish contact with BUS:Y Bus Failure 5 1. Node:X stops receiving Watchdog Reset signal on BUS:X, due to CAN transceiver or CAN controller failure. 2. Node:X toggles to BUS:Y 3. Master CPU detects traffic on BUS:Y 4. Master CPU transfers Node:X back to BUS:X to make sure the transfer not was provoked by a transient problem, either by not transmitting a Watchdog Reset signal on BUS:Y or by transmitting a forcing CAN message. 5. If Master CPU decides to switch bus, the Watchdog Reset signal on BUS:X is terminated and transferred to BUS:Y. 6. All sub-systems will establish contact with BUS:Y
Bus Failure 6 1. BUS:X is shorted to ground or supply voltage 2. All users on the bus will detect form errors, bit stuffing violations, and errors in the reception of self-transmitted messages. This will prompt them to transfer communications to BUS:Y. 3. The Master CPU transfers the users back to BUS:X to make sure the transfer was not provoked by a transient problem. The users toggles back to BUS:Y. 4. The Master CPU terminates the Watchdog Reset signal on BUS:X and start transmitting it on BUS:Y.
6.2
Warm Redundancy
Instead of letting the Master CPU handle the monitoring of the bus and the signalling of bus transfer (Watchdog Reset signal) the system could be designed to function with two physical buses working in parallel. The nodes send a periodic Im OK signal on the bus.
Figure 22. Warm redundant node design overview
The basic system idea: Single CAN core in each node

Dual transceivers in each node Receiver stage AND gate Master CPU watchdog that is reset every time an Im OK signal is received. When the Master CPU Watchdog times out the system is re-started Watchdog in each node, possible to override from local CPU Watchdog is reset at every signal level transition When the watchdog times out, the CAN node toggles to the other transceiver. Watchdog times out after T = (Tstuff +1) + 2xTerr.
The maximum dominant time allowed in a the data field is limited by a stuffing rule that states that after 5 consecutive bits of the same polarity a bit of opposite polarity must be inserted in the bit stream. This time (5*bit time) is Tstuff. When detecting a violated stuffing rule the CAN controller starts to issue error flags in the bit time following Tstuff +1. These error flags can last up to 2xTerr . Monitoring of a stuck-to-dominant fault is thus easily achieved using a watchdog timer that
is set to Tsd = (Tstuff+1) + 2xTerr. (Tsd being the time a stuck-at-dominant failure is detected) The system goes through the same start-up sequence as a cold redundant system. Bus Failure 1 1. BUS:X is broken between CPU:X and PWR:ABC 2. The receiver from BUS:X supplies one of the inputs of the AND gate on the receive stage with an idle signal, i.e. a logic HIGH. This has no affect on the signal transmitted to the PWR:ABC CAN controller, as the bus signal from BUS:Y then controls the gate. Bus Failure 2 1. BUS:X is broken between CPU:X and TC:A 2. TC:A continues transmission using BUS:Y. The broken BUS:X supplies one of the inputs of the AND gate on the receive stage with an idle signal, i.e. a logic HIGH. This has no affect on the signal received by TC:A, as the bus signal from BUS:Y then controls the gate. Bus Failure 3 1. BUS:X is broken between CPU:X and Node:X. 2. Node:X continues transmission using BUS:Y. The broken BUS:X supplies one of the inputs of the AND gate on the receive stage with an idle signal, i.e. a logic HIGH. This has no affect on the signal received by Node:X, as the bus signal from BUS:Y then controls the gate. Bus Failure 4 1. BUS:X is shorted to ground. 2. The transmission of data and commands are continued via BUS:Y. 3. The nodes receivers see a constant logic LOW, i.e. a dominant bit on the bus, and after Tsd the Watchdogs time out. 4. The input to the receivers AND gates is toggled to a logic HIGH, to remove the influence of the faulty bus on the individual receiver stages, and the system is controlled by the contents of BUS:Y. Bus Failure 5 1. 2. 3. 4. BUS:X is shorted to supply voltage. The transmission of data and commands are continued via BUS:Y. The receivers see a constant logic HIGH, i.e. a recessive bit on the bus. The AND gates on the receiver stages are unaffected by this and the contents of BUS:Y is coming through to the CAN controllers.
Bus Failure 6 1. The AND gate on CPU:A is damaged. 2. CPU:A loses the Im OK signal from the nodes. 3. The Master CPU watchdog times out and the system goes to start-up again
Bus Failure 7 1. The AND gate on Node:X is broken. 2. The CAN controller in Node:X takes the Node into off-bus state, the bus is unaffected. Bus Failure 8 1. The AND gate in TC:A is damaged. 2. The CAN controller in TC:A takes TC:A off-bus. 3. TC:B is still functioning and the operation of the bus is unaffected. Bus failure 9 1. The AND gate in PWR:A is broken. 2. The CAN controller in PWR:A takes it off-bus. 3. PWR:BC are still functioning and the operation of the bus is unaffected.
7
7.1
Medium / High level protocol considerations

Mapping of ESA telemetry standard on CAN
The CCSDS recommendation for packet telemetry, is a technical recommendation for use in developing packetized telemetry systems. It establishes a common framework and provides a common basis for the data structures of spacecraft telemetry stream. A CAN message has a maximum of 8 bytes of data. To map the CCSDS standard into these 8 bytes would mean that the actual data transmitted would be severely reduced, as the majority of the data space would be occupied by CCSDS overhead. This CCSDS overhead contains among other things packet ID, sequence control flags, and data length. The packet header itself consists of 6 bytes, leaving a maximum of 2 bytes for actual data. Part of this overhead would be pure redundancy if mapped on a CAN message, for example the CAN frame arbitration field, serves the same purpose as the application field in the CCSDS packet. This can be argued for other CCSDS packet fields as well. Those not supported in the CAN frame, such as sequence control is easily implemented using predefined bit patterns in the CAN frame arbitration field. As a result of the study it was concluded that the design of the CAN protocol allows for transmission of pure CAN messages without the CCSDS packet overhead.
7.2
CAN protocol suggestion
7.2.1 Identifiers
The CAN-bus is a multimaster bus with deterministic behaviour with message priority based on a message identifier. The use of this identifier controls much of the behaviour of a distributed control system based on the CAN-bus. In CAN 2.0B, the identifier is 29-bits long and below is a suggestion how to use these address bits. Using the two most significant bits, we divide the messages into four types:

Supervisory Mode Command Mode - high priority Command Mode - standard Data transfer
Bit 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Supervisory 1 1 Priority Priority Priority Priority Priority Priority Priority Priority Adress Adress Adress Adress Adress Adress Adress Adress Command Command Command Command Command Command Command Command Command Command Command Command 1 0 Priority Priority Priority Priority Priority Priority Priority Priority Adress Adress Adress Adress Adress Adress Adress Adress Command Command Command Command Command Command Command Command Command Command Command Command 0 1 Priority Priority Priority Priority Priority Priority Priority Priority Adress Adress Adress Adress Adress Adress Adress Adress Command Command Command Command Command Command Command Command Command Command Command Data 0 0 data type data type data type record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID record ID
7.2.2 Modes
Supervisory mode The supervisor mode is only used at extraordinary events such as system startup, subsystem fault debugging, system reconfiguration etc. It could also be used to override the system from ground via the telecommand/telemetry system. Examples are: forced reboots hard interrupts setting of hard security levels, max current etc. remote code loading remote boot with code download direct monitoring Command Mode High Priority High priority commands involves essential systems and operations, for example real-time commands between sensors and actuators on a three-axis stabilized satellite. Normal Priority Normal priority commands involve non-time critical operations, such as deployment of solar cell arrays, opening/shutting blinds, battery charging. Data mode In Data Mode, users get assigned a record ID and a record length. One or more storage devices record the transmitted data along with the record ID when ordered. When the record is full, the users get a new record ID. The transmit-onaddress scheme allows for transparent use of redundant data storage devices. Storage Record Format: (24-bit identifier + 5-bit data type code) * 8-byte records Data type code #000 indicates long record and the next 32-bit word gives the record length N x Bytes data Maximum of 16 million records Maximum record length: 4 GByte Maximum number of minimum records in 512 MByte: 4.5 M records with only 66 % efficiency. 64 Byte records give 94 % efficiency. Full data rate on CAN is about 8000 msgs/second: fills up 512 MByte in 1.5 h. Example with one Storage Device, One Payload Master and several instruments. 1. Payload Master to Storage Device: Record On Record ID: #00FF01 and length: #8F (128 x 8-byte) 2. Payload Master to Instrument One: Take 128 samples of 4x16 bits with 10 seconds interval Use Record ID: #00FF01 and length: #8F Start Now 3. Payload Master to Storage Device: Record On Record ID: #00FF06 and length: #00, #0000FFFF (64 kByte) 4. Payload Master to Instrument Two: Take picture Use Record ID and length: #00FF06, #00, #0000FFFF (64 kByte) Snap Now
8
8.1
System architecture example

Introduction
Two Completely independent sets of redundant CAN-buses Essential bus Payload Bus On the essential bus, only three systems are allowed to act in the Supervisory Mode: TC/TM: (Highest Priority) (Power Controller) System Master On the Payload Bus, the following systems are allowed to act in the Supervisory Mode: TC/TM: (Highest Priority) (Power Controller) System Master Payload Master
8.2 Basic assumption and preferences

The basic preferences are: Splitting up Essential System Control (ESC) and PayLoad Control (PLC) Use 32-processors with COTS development tools for both ESC and PLC Design/use identical units for the both ESC and PLC, combined with 1-2 cold redundant units Logical bus for Essential and Payload communication Redundant media access devices for both busses ESC, PLC and TM/TC system can access both Essential and Payload bus Preferrably use electrical star coupling of busses with central, redundant Hubs In addition: Design/use local DRAM based solid state recorders on ESC and PLC as Mass Memory Use "simple" and reliable microcontrollers for PWR and TM/TC controll (with direct access to local registers and functions from bus) Solve auxillary/off-shelf I/O via "dumb" interface units based on FPGAs All subsystems with processor should have an UART interface to facilitate direct access during development and system integration, together with a PC based graphical interface, e.g. Labview The PWR controller can function as a Lizard brain for the complete system and supervise the ESC node. The TM/TC node should have the possibility to overide all but the most essential functions, i.e. PWR

PWR CNT 1 hot+ 1 cold
16-bit CPU 64k R AM 8k+128k ROM
Earth Sens
Gyro CNT
Star tracker
Earth Sensor
C AN
X-band Tx Aux-CNT System CNT Memory

32-bit CPU 3 2M ED AC RAM 32k ROM 1M EEPR OM 0.5 GByte
Payload CNT Memory

32-bit CPU 32 M ED AC RAM 32k ROM 1M EEPR OM 0.5 GByte
TM/TC
S-band Rx S-band Tx
Auxillary I/O
1 hot+ 1 cold
Passive CAN
3 indentical processor nodes 2 hot +1 cold
2 hot ? Active back-up 1 M bit/s
Experiment A
Experiment B
Experiment C
Experiment D
Figure 23. Overview of typical system architecture.
8.2.1 Main controller

The baseline for that Main Controller incorporates:

PPC603e 32-bit processor (200 MIPS, 50 MFLOPS) 64/70 Mbyte DRAM main memory EDAC Radiation tolerant Boot PROM 512 Mbyte EDAC DRAM in banks possibly 1-8 Mbyte EEPROM (depends on radiation tolerance) CAN-bus interface (dual redundant)
This subsystem could be configured to run both as Main controller and as Payload controller.
Figure 24. Subsystem interface unit.
8.2.2 Payload drop-in unit

A standard drop-in payload unit can be designed that incorporates:

32-bit microcontroller (StrongArm, Leon-1) EDAC DRAM/SRAM CAN-bus interface (dual redundant) with remote boot Configured to run small operating system

Remote Debugg mode Remote power control Latch-up protection
8.3
Essential Communication
20 Hz update data readout transaction with 8 data words each (0.16 ms) control transactions with 8 data words each spare transactions 100 us set-up / latency 10 transactions of 10 16-bit words at 1 Mbit/s = 10*(10*16 +100)*1e-6 = 2.6 ms 20 Hz is 50 ms period, 2.6 ms/50 ms = 5.2 % of available bandwidth
8.3.1 AC/DC communication
8.3.2 Supervision and housekeeping

5 Hz 10 transactions with 8 data words each 10 transactions of 10 16-bit words at 1 Mbit/s = 10*(10*16 +100)*1e-6 = 2.6 ms Hz is 200 ms period, 2.6 ms/50 ms = 1.3 % of available bandwidth
8.4
Payload Communication
The payload communication is handled through redundant CAN-busses, each operating at 1 Mbit/s. The CAN system can handle up to about 8000 msgs/s, and about 400 kbit/s in data bandwidth. This would probably be more than the downlink can handle. Local buffering should be used to even out burst acquisitions.
8.5
System priority
There must be a structured functional architecture defined in the system with assigned priorities and levels of command. In Figure 25, a general division is made between different levels. This must of course be refined and modified depending on mission, modes etc.
Figure 25. Priority levels.
The system is based on an autonomous power system that always maintains a regulated main bus voltage according to standards suggested by ESA. To switch different redundant sub-systems on and off, some form of intelligence is required, in our case a Lizard Brain function. It could consist of voting simple CPUs with compact software but other possibilities exist. The main task is to boot up and monitor the functions of the System Controller and the TM/TC subsystems. It will also function as the interface to the power system. When one TM/TC system and one System CNT are operational, they start by loading "Basic Services" functions,
such as direct "terminal mode" from ground for the TM/TC system and applying basic attitude control for the System CNT. This could be defined as a safe mode type of operation. These services should be implented as high priority processes/drivers. When all lower levels functions correctly, System applications can operate. These provide more intelligent control, data handling, on-board decision making etc. On top of the System applications, payload control payload applications run.
8.6
Start-up
1) Power system (OK) 2) Lizard Brain (16-bit CPU, Triple majority voting CPU or triple majority voting watchdog with cold redundant CPU) 3) Lizard Brain controls Main controller (Polling boot; Main, Payload, Redundant) (3.b starting telemetry safe mode, ACDC safe mode) 4) Main controller monitors and controls essential subsystems 5) Essential subsystems, ACDC, thrusters, . 6) Main controller starts (controls) payload controller 7) Payload controller controls payload 8) Payload Boot procedure: 1) Power bus voltage established (all subsystems off) 2) Lizard brain failsafe boot (Tripple majority voting CPU or Tripple majority voting watchdog with cold redundant CPU) 3) Lizard brain boots (power on) on Main controller [Main, Payload, Redundant] 4) Power on: wait 1 sec, if no answere on 1553, go to next Controller 5) If all three fail, start Telemetry system in failsafe mode as 1553 Bus controller 6) Main controller starts essential subsystems 7) Possible polling start of redundant subsystems 8) Main controller starts Payload controller 9) Main controller enables Payload instruments
References
Ref 1 ISO 11898:1993, Road vehicles Int erchange of digital information Controller area network (CAN) for high-speed communication, Nov 1993 Ref 2 Ref 3 Statement of Work, ESTEC, April 1999 Packet Telemetry, CCSDS 102.0-B-4 Blue Book, Nov 1995 ftp://ftp.estec.esa.nl/pub/ws/wsd/CAN/canspace.htm http://www.canhug.org/ http://www.kvaser.org/ http://www.can-cia.de/ http://www.odva.org/ http://content.honeywell.com/sensing/prodinfo/sds/ Smart Distributed System (Honeywell). http://www.bosch.de/de_e/productworld/k/ products/prod/can/Bosch http://141.44.61.248/NT/CAN/Welcome.html IPE CAN Home Page, University of Magdeburg. http://www.docs.uu.se/~ken/ http://www-us.semiconductors.philips.com/can/ http://www.mfuniversity.com/siemens/homepage.htm http://www.algonet.se/~staffann/developer/CAN.htm http://www.can-cia.de/pc.htm http://www.can-cia.de/pth.htm
CAN for space CAN HUG CAN Kingdom CiA ODVA SDS Bosch IPE CAN Ken Tindell Philips Siemens Institute Staffan's CAN page CAN controllers CAN tranceivers
10
List of books and links

Wolfhard Lawrenz CAN System Engineering : From Theory to Practical Applications Springer, 1997 ISBN 0-387-94939-9 Wolfhard Lawrenz (Hrsg.) CAN Controller Area Network - Grundlagen und Praxis Hthig, 1999 ISBN 3-7785-2734-7 Konrad Etschberger (Hrsg.) CAN Controller Area Network - Grundlagen, Protokolle, Bausteine, Hanser, 2000 ISBN 3-446-19431-2 Dominique Paret Le Bus CAN DUNOD, 1997 ISBN 2-10-003164-3 More books under http://www.bosch.de/de_e/productworld/k/products/prod/can/content/Literature.ht ml

CAN Application in Avionics

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

CAN Application in Avionics

Caricato da

Copyright:

Formati disponibili

CAN application in avionics Final Report

Gruvgatan 8 S-421 30 Gteborg Sweden Authors: Anders Emrich