Printer Friendly

Analysis of CANaerospace Protocol Communication Quality in Aviation System.

I. INTRODUCTION

The aim of the paper is to present an aircraft on-board electronic system for data collection from sensors placed on aircraft devices. The complete system is shown in figure 1. The primary task was to select a data bus for communication between individual modules suitable for carrying important flight or aircraft parameters [12]. The selection of a suitable data bus depended mainly on specific requirements such as baud rate, robustness, reliability, number of nodes in the network, type of aircraft (civilian or military) and price. Currently, the ARINC429 data bus is used as an on-board bus for radio-navigation communication; ARINC 629, and AFDX [16] are used as the main spine-buses of large passenger aircraft; MIL-STD-1553, and MIL-STD-1773 are used in military aircraft; IEEE 1394b [3] is used in unmanned vehicles and tactical military aircraft. For the proposed aircraft on-board electronic system, the Controller Area Network (CAN) [1], [12], [14], [18] was selected. The CAN bus communication is based on a different principle. A so called message identifier is assigned to each individual message according to its content, defining clearly and unambiguously the content of the message and at the same time giving the priority of the message. CAN bus for avionic systems is specified by the CANaerospace protocol [2-3], [15].

II. MATHEMATICAL ANALYSIS OF THE COMMUNICATION

Generally, aviation systems require a more accurate method of data transfer. That can be achieved if Time-triggered communication via CAN (TTCAN) is used, as specified in the ISO 11898-4 Standard [6-7], [17]. Then bus communication control will change into TDMA (Time Division Multiple Access) [3]. The principle of the TTCAN protocol is based on the so called Cycle Matrix figure 2, clearly defining message time schedule for individual participants on the bus.

A complete avionic system provides an enormous amount of data [10]. A flight plan is divided into sections (start section, accent and flight speed increase, flight according to the given or selected course, change of altitude, change of speed, assault completion, descent and flight speed decrease, landing positioning, landing).

These individual flight sections do not require the same data. Each flight section needs different specific data. Each section of the flight has a different Cycle Matrix. That means that at the beginning of each flight section a reconfiguration of the existing matrix is needed. Therefore, several Cycle Matrixes are defined for several sections of the flight. Each matrix does not have to have the same number of elements. The amount of elements depends on what frequency the given flight or aircraft parameter will be transmitted at, on the number of flight parameters and on the system baud rate. Bus capacity can be a limiting parameter. This different method using a time schedule for transmitting individual messages via CAN bus, complying with CANaerospace protocol, is called a dynamic time-slot assignment in the Cycle Matrix. The command for transformation into a new required matrix can also come from the integrated environment Network Enabled Capability (NEC) [3], [13], where the land staff or command centre requests which data is the most important for them at that moment. For some flight sections, Cycle Matrixes can be completely different and for other sections very similar.

After evaluation of the data bus behaviour, certain parameters needed to be created to quantitatively express the bus communication level. The most important parameters for mathematical analysis of data bus behaviour are the capacity [C.sub.CANAS] and bus utilisation U [3]. It is important to get these parameters from elementary values.

Data frame length [n.sub.D] was chosen as an 11 bit identifier. When the identifier is 11 bits, there can be [2.sup.11] messages, which is 2048. This amount of messages is more than sufficient for the proposed on-board aircraft electronic system. The data frame length [n.sub.D] is given by the following equation:

[n.sub.D] = round[34 + 8[N.sub.D]/5] + 47 + 8[N.sub.D], (1)

where ND is the amount of data bytes.

Function round means rounding down to the nearest whole number because of the insert mechanism so called stuff bites [1].

1 bit transmission time [tau] is defined as a reciprocal value of the bus transfer speed:

[tau] = 1/baud rate, (2)

The message transmission period is a very important parameter for all the following calculations. It is measured when the data bus is 100 % utilized i.e. when the messages are transmitted immediately one after another. The message transmission period pU100% is defined as:

[p.sub.U.sub.100%] = [n.sub.D][tau], (3)

Bus capacity [C.sub.CANAS] represents the number of messages that are able to be sent via the bus within one second. The capacity can be defined as:

[C.sub.CANAS] 1/[p.sub.U.sub.100] (4)

Maximum bus capacity is 8771 messages/s at a maximum baud rate and a minimum number of stuff bits. Maximum capacity depends on the number of inserted complementary bits within the bit stuffing process. The stuff bits occurrence is very stochastic.

In this stage it is possible to evaluate bus utilisation. Two types of messages can be transmitted via the bus and for each one there is a different way of calculating utilisation. The first type are messages transmitted regularly, so called synchronous messages, the second type is transmitted randomly, so called asynchronous messages. For the synchronous messages bus utilisation is defined as:

[mathematical expression not reproducible] (5)

where [U.sub.S] is bus utilisation by synchronous messages, [n.sub.S] is the frame length of the synchronous transmitted messages, [tau] is 1bit transmission time and [p.sub.S] is the frame transmission period of synchronous message.

Bus utilisation by asynchronously transmitted messages is defined as:

[mathematical expression not reproducible] (6)

where [U.sub.AS] is bus utilisation by asynchronous messages, nAS is the frame length of asynchronously transmitted messages, [tau] is 1bit transmission time, [x.sub.AS] is the number of transmitted asynchronous message frames.

CANaerospace specification recommends utilising the bus at 80 % for synchronous messages to have sufficient bus capacity available in case of transmitting asynchronous CANaerospace messages.

III. ALGORITHM FOR CYCLE MATRIX DESIGN

The first step for proposing a Cycle Matrix is to know the number of transmitted messages and the message transmission periods. The message transmission periods are given in the CANaerospace specification [2]. From the number of transmitted messages and the calculated transmission periods, the time needed for 1 bit transmission, corresponding to a certain bus baud rate when the bus is 80 % utilised by synchronous messages, needs to be calculated. 1 bit transmission time formula can be deduced from the above formula (5) and is:

[tau] = 80/[n.sub.S] [M.summation over (i=1)] 1/[p.sub.S]. 100 (7)

From the calculated baud rate a one element length [t.sub.s], so called Cycle Matrix time-slot, needs to be determined using the following formula:

[t.sub.s] = [n.sub.s] [tau], (8)

Here, a time reserve can be set up to assure correct message transmission by timing one time frame length by a chosen constant. In case of using the highest number of stuff bits, where the number of message bits is 135 [1], a certain time reserve is already set up. The next step is to determine the number of time frames in a period, where the longest period determines the number of the Cycle Matrix elements. In the case where the number of transmitted messages is high, the longest period represents a multiple of the number of Cycle Matrix elements. The following formula shows determination of time frames corresponding to the transmitted message period:

c = [p.sub.S]/[n.sub.S][tau], (9)

After this, the reference message transmission period needs to be determined to time-synchronise the system. The reference message period will specify the number of Cycle Matrix rows. Then it was easy to calculate the number of columns and then determine the final matrix size. After that the individual messages are progressively assigned into the prepared matrix according to the time frames and their corresponding message periods. In the end the transmitted message periods need to be verified, bus utilisation needs to be verified according to the designed Cycle Matrix and the assignment time of the Cycle Matrix needs to be analysed.

Assignment time of the Cycle Matrix depends on the amount of elements in the matrix itself. The complete onboard aircraft electronic system provides a large number of messages. Just for your information, the time needed for Cycle Matrix reconfiguration with a maximum possible number of elements, specified by the CANaerospace protocol, at a baud rate of 125 kbits/s is 70778.88 ms, which is 1 minute and 10.78 seconds. This time, when the system is not providing any data is too long and can have fatal consequences for flight safety. Using a maximum system baud rate of 1 Mbit/s can reduce this value to 8847.36 ms, which is 8.85 seconds. This time is also quite long and therefore a compromise is needed between transmission period of synchronous messages, the amount of transmitted messages required and the amount of elements in the Cycle Matrix. If, according to the CANaerospace specification, the maximum possible number of Cycle Matrix elements must be used, a different reconfiguration algorithm for Cycle Matrix must be used [20].

IV. COMMUNICATION ANALYSIS OF COMPILED AVIONIC SYSTEM

Communication analysis of the compiled on-board avionic system via a CAN bus with the CANaerospace protocol was conducted on seven modules allowing the transmission of a total of fifteen messages carrying flight or aircraft parameters. The cores of the individual modules were AT90CAN128 microcontroller with a built-in CAN driver. The first module was an inertial sensor module providing acceleration in three axes and angular velocity around three axes of the aircraft coordinate system. Another module was providing information from turn coordinator in [degrees]/s. Another module was for temperature measurements sending values such as static temperature, mid air layer temperature under the aircraft, which is an important value for calculation of barometric height in an air data computer, and cockpit temperature. Another module was for current measurements assuring transmission of information about current of the DC power supply. Another two modules carried data about aircraft altitude and the temperature of engine outlet gases. The last module, providing flight or aircraft information, was giving information about aircraft engine vibrations. The MASTER module was a very important module, controlling all communication. It received three messages: a command for assignment of the communication time schedule and commands to start and end communication [3], [8-9], [11], [19], [21]. The module assured assignment of communication time schedule and also periodically transmitted a reference message RM assuring time-synchronisation of message transmission from the individual modules. The last but not least module of the system was an NEC interface module transmitting a message for assignment of the communication time schedule and a command for the start and end of the communication. The CAN IDs of the individual messages were selected according to the CANaerospace protocol. The system on which the experiments, regarding correct CAN bus communication with the CANaerospace protocol, were made is shown in figure 3.

A nine-wire 40 m long flat cable was used to connect all the modules. The cable length was selected as the maximum possible length for the baud rate of 1 Mbit/s [1], [3-5] and the cable was unshielded. CAN 9 Z S clip-on sockets were attached to the cable along the whole length at various distances. The cable had terminal resistances of 120 [ohm] on each end.

Transmission periods for each individual flight or aircraft parameter and the reference message are shown in figure 4. For these transmission periods a system baud rate was calculated at 124.706 kbit/s and was rounded to 125 kbit/s which is a value easily set in the timer register of the MASTER microcontroller. Therefore one time frame length was 1.08 ms. The number of time frames, corresponding to the selected periods, and consequently corrected values of periods are again shown in figure 4. A Cycle Matrix with 12 rows and 20 columns was designed. According to the mathematical analysis the proposed Cycle Matrix assigning time reached 259.20 ms. Bus utilisation was then 77.67 %, according to the theoretical calculation, which complies with the CANaerospace protocol.
Figure 4. Transmitted Messages Parameters

Flight or Aircraft  Symbol           CAN ID  Transmission
Parameters                           [hex]   Period [ms]

Reference
Message             RM               081      12.5
Accelerations x     [a.sub.x]        12C      12.5
Acceleration y      [a.sub.y]        12D      12.5
Acceleration z      [a.sub.z]        12E      12.5
Angular Velocity    [[omega].sub.x]  12F      12.5
x
Angular Velocity    [[omega].sub.y]  130      12.5
y
Angular Velocity    [[omega].sub.z]  131      12.5
z
System DC           [I.sub.D]        3A2      40
Current
Static              [T.sub.s]        144      40
Temperature
Mid Air Layer       [T.sub.m]        143      40
Temperature
under the Aircraft
Engine Turbine      [T.sub.c]        208      40
Outlet
Temperature
Turn Coordinator    [[omega].sub.T]  14B      40
Value
Height              H                14C      40
Vib ration          [a.sub.V]        2B4      40
Cockpit             [T.sub.C]        14F     250
Temperature

Flight or Aircraft  Number of       Corrected
Parameters          Time-slots [-]  Trans mission
                                    Period [ms]

Reference
Message              12              12.96
Accelerations x      12              12.96
Acceleration y       12              12.94
Acceleration z       12              12.96
Angular Velocity     12              12.96
x
Angular Velocity     12              12.96
y
Angular Velocity     12              12.96
z
System DC            37              39.96
Current
Static               37              39.96
Temperature
Mid Air Layer        37              39.96
Temperature
under the Aircraft
Engine Turbine       37              39.96
Outlet
Temperature
Turn Coordinator     37              39.96
Value
Height               37              39.96
Vib ration           37              39.94
Cockpit             240             259.20
Temperature


The proposed Cycle Matrix is shown in figure 5. The CAN ID value represents individual messages in hexadecimal code.
Figure 5. Proposed Cycle Matrix

081  143  12C  12D  144  12E       208  12F       3A2  130       2B4
081       12C  12D       12E            12F            130
081  144  12C  12D  208  12E       3A2  12F       2B4  130       14B
081       12C  12D       12E            12F            130
081  208  12C  12D  3A2  12E       2B4  12F       14B  130       14C
081       12C  12D       12E            12F            130  143
081  3A2  12C  12D  2B4  12E       14B  12F       14C  130
081       12C  12D       12E            12F  143       130  144
081  2B4  12C  12D  14B  12E       14C  12F            130
081       12C  12D       12E  143       12F  144       130  208
081  14B  12C  12D  14C  12E            12F            130
081       12C  12D       12E            12F            130

081       14B  131       14C
081            131  143
081       14C  131
081  143       131  144
081            131
081  144       131  208
081            131
081  208       131  3A2
081            131
081  3A2       131  2B4
081            131
081            131       14F


Verification of communication behaviour for the proposed Cycle Matrix has already been done and evaluated in [3]. All the tests were conducted using a diagnostic tool, created in the National Instrument Company's LabVIEW [3], [15] development environment. A NI USB-8473 High-Speed CAN module was used as an interface for a PC or laptop.

V. PROGRESSIVE MESSAGE ENTRIES AND MAXIMUM BUS UTILISATION AT A BAUD RATE OF 125 KBIT/S

The other part of our experiment focused on entering messages into the system and their dependency on adjustable comparison values set in the timer register. The message entries should theoretically correspond to a reference message transmission period and to the maximum bus utilisation, achievable for a certain number of Cycle Matrix columns. The testing was conducted in a laboratory environment for a baud rate of 125 kbit/s, and for 2 module distances from the diagnostic device of 0 and 40 m. A Cycle Matrix of 5 rows and 13 columns figure 6 was chosen for the communication time schedule. An initial value of 100 [micro]s was inputted into the comparison timer register of the MASTER block. This value was gradually increased by 50 [micro]s until all messages entered, i.e. all Cycle Matrix columns entered, and the following parameters were measured respectively: total bus utilisation, reference message transmission period, transmission message periods of flight or aircraft parameters, development of individual message entries, and the number of individual message transmissions after determining the correct communication quality.
Figure 6. Time-slots Assigment to Individual Messages According to CAN
ID

RM  3A2  143  144  14F  12C  12D  12E  12F  130  131  208  14B  14C
RM  3A2  143  144  14F  12C  12D  12E  12F  130  131  208  14B  14C
RM  3A2  143  144  14F  12C  12D  12E  12F  130  131  208  14B  14C
RM  3A2  143  144  14F  12C  12D  12E  12F  130  131  208  14B  14C
RM  3A2  143  144  14F  12C  12D  12E  12F  130  131  208  14B  14C


Dependency of total bus utilisation and of a measured reference message transmission period on an adjustable reference message period, corresponding to the value in the comparison timer register is shown in figure 7.

This chart in figure 7 shows that the highest bus utilisation, nearly 100 %, of the system is reached at a theoretical reference message period of 1 ms. With higher values of reference message periods than 1 ms, the bus utilisation decreases. A reference message period of 1.15 ms covers a section, where the communication is quite unstable and the bus utilisation fluctuates between 88 - 98 %. The reason for this is that many messages from the first five columns of the Cycle Matrix were entering at the same time with different periods, in essence, randomly. This chart section continues until the synchronisation message period reaches 5.4 ms. Then the communication is very stable, the transmission periods of the individual messages are practically identical - they fluctuate only in an order of hundreds of a millisecond, and the bus utilisation slightly decreases from 93.26 to 91.17 %. At the value of 10.95 ms bus utilisation starts to decrease steeply, but no instability is shown. Step changes always represent a new message entry. After the last message of the time schedule entered, the bus utilisation stopped at 70.37 % which is the maximum reachable value for such a setting. Another parameter that was generated was dependency of the measured synchronisation message period on the adjustable reference message period and was marked in the same chart but on an auxiliary axis. The important changes curve is copying the total bus utilisation curve. In the beginning there is a constant value of the measured reference message period of 1.98 ms. Unstable communication is represented by fluctuations in the reference message period between 5.8 - 6.8 ms. Stable communication shows practically constant period value and the entries of individual messages are clearly visible from the step changes. At the steep decrease of bus utilisation the reference message transmission period linearly increases, except for the two situations where message entry meant a step change of the period. After all the messages entered the synchronisation message period reached 20.42 ms. The system behaved practically the same for both module distances from the diagnostic tool, the curves overlapped.

For a detailed view of progressive behaviour and individual message entries it was necessary to create a table describing important changes in communication during comparison value adjustments in the timer register of the MASTER block microprocessor and providing all measured message periods, number of transmitted messages and the total bus utilisation. The table also revealed new information about messages entries via the CAN ID. It is clear that, mainly at the end of the experiment, some messages were entering in a different order than was given by the Cycle Matrix. Message 14B entered before message 208. This fact can be most likely explained by the following assumption. The basic principal of time-triggered mode in a microcontroller driver is that each message is transmitted only once, there is no other arbitration process. In this case, the messages 14B and 208 are placed at the end of the Cycle Matrix and when the length of one time frame starts increasing another message with lower CAN ID quickly enters, thus having higher priority than, for instance, the CAN ID 3A2 message - having a lower priority in this system. This CAN ID 3A2 message is in the beginning of the time schedule, time assigned to one time frame is very short, and thus no message have time to jump in front of this message even if it had a higher priority. To count the number of transmitted messages and consequently evaluate the communication quality a number of transmitted reference messages were chosen at 100 000 and the analyses was stopped after reaching 100 000 transmitted reference messages. The full completed table [3] showing the most important instances in communication is very extensive and therefore is not part of this article.

VI. PROGRESSIVE MESSAGE ENTRIES AND A MAXIMUM BUS UTILISATION AT A BAUD RATE OF 500 KBIT/S

For comparison with previous tests the same environment and test conditions were applied. The only difference was that the communication was carried out at a baud rate of 500 kbit/s. To measure the dependency of the total bus utilisation and of the reference message period on the calculated reference message period, different values were progressively adjusted in the comparison timer register of the MASTER block microcontroller. These adjustable values needed to be, compared to the previous tests, reduced accordingly. The test started at the value of 12 [micro]s and was gradually increased by 12 [micro]s. The purpose of this test was to increase this value until all messages had entered, i.e. all 13 columns of the Cycle Matrix. But at this set baud rate only 11 messages had entered (11 Cycle Matrix columns). When increasing the value in the comparison timer register of the microcontroller, some messages started to have different transmission periods, i.e. some entered the system more than once and some less than they should, which is a sign of poor communication quality. Eleven columns in the Cycle Matrix was the limiting factor for this type of setting at this set baud rate. The measured dependency is shown in figure 8.

The depicted dependences show no information about the progressive entries into the communication system, which is quite important for quality verification. Here, for example, the message 3A2 entered as sixth and should have entered first according to the time schedule. The most important instances of communication and parameter processing are shown in a comprehensive, but extensive, table that is not included in this article. In the charts shown, there is no major fluctuation in bus utilisation or in reference message transmission. only in the beginning of the chart, up to the calculated reference message value of 0.250 ms, the bus utilisation steeply decreases. That was caused by the fact that no other message, except the reference message, entered the system. From the value of 0.250 ms, when the first flight parameter message entered the system, the bus utilisation steeply increased and then decreased regardless of other message entries. From the adjustable reference message period of 0.564 ms the bus utilisation slowly increases. The step changes clearly show entry of another two messages. From the reference message period value of 1.2 ms, the bus utilisation remained constant at 89.91 % and no other entries were clearly visible. That was visible from the reference message period waveform. step changes occurring at sections of approximately 0.270 ms, corresponding to a maximum message length without a time reserve, signalled entry of one message. Longer constant sections represent entries of several messages. Linear sections represent an increase of a period of constant message density. At the end of the measurements the total bus utilisation value was 87.92 % and the reference message period was 3.357 ms. Generally, it is possible to state, that communication at this transfer speed and with this Cycle Matrix setting is more stable than at the above described settings, and there is no graph section with major fluctuations in both bus utilization and reference message transmissions. However, one problem has arisen. When a timer register comparison value in the microcontroller is set to a certain value, corresponding to an adjustable reference message period of 1.140 ms and 1.620 ms, several messages enter the system literally simultaneously. That is not required by the communication time schedule and what's more, it is impossible to set such a comparison value that all messages could enter. The system, also at this baud rate, behaved the same for both module distances from the diagnostic tool, both curves overlapped.

VII. COMMUNICATION AT BAUD RATE OF 1 MBIT/S

Baud rate of 1 Mbit/s is, according to the literature [1], [3-5], the technological limit for the CAN bus. Therefore, the communication initiation was only conducted on one module transmitting only one message. At first, the module was connected as close as possible to the diagnostic tool. The message was transmitted with a constant, non-fluctuating period, bus utilisation was stable, i. e. the communication was faultless. Then, the module was connected at a distance of 40 m from the diagnostic tool. The message was transmitted with a period fluctuating in the wide range of 129 - 467 [micro]s and with bus utilisation of 26.34 - 95.15 % the system showed huge message entry irregularities and poor quality of communication.

The module distance from the diagnostic tool was gradually decreased, and the transmission period and the bus utilisation were measured until they settled on a particular constant value. A maximum distance of 2.83 m from the diagnostic tool was achieved. The measured parameters settled at a value of 191 us for message transmission period, and 64.33 % for bus utilisation. Both values were maximum values allowed by the module microcontroller with a crystal oscillator frequency of 8 MHz. After this verification, all modules were connected to the complete system with the last module connected to the system at the distance of 2.83 m from the diagnostic tool. In such a configuration it was not possible to initiate communication at the highest baud rate. It is most likely that when using the highest baud rates the focus needs to be on individual segments of one transmitted bit such as segment regarding propagation time of electromagnetic wave in the wiring, sampling instance, and transmitting instance, all of which are set in three registers of the microcontroller. There are several combinations of register settings available for one baud rate, therefore the most suitable combination should be specifically set for each module according to the electromagnetic wave propagation time in the wiring. It was experimentally discovered that a changing some register values by 2 can cause a communication interruption. The frequency fluctuation of the crystal oscillator could also affect the time synchronisation. The frequency can vary for different modules. In all modules a crystal oscillator with a frequency of 8 MHz was used. Just out of interest, frequency of one module was measured by oscilloscope and the frequency of 7.90 - 8.16 MHz was confirmed. The reason for reaching such a short distance between the module and the diagnostic tool during a good quality communication is also the fact that the cable was not shielded.

Figure 9 shows the laboratory work place with all modules connected.

VIII. CONLUSION

The main contribution of the paper is proposal of communication time schedule of real avionic system, its verification and communication analysis.

The most valuable part of this article was the analysis of progressive message entries while adjusting the value in the timer register of a comparison MASTER block microcontroller as a Cycle Matrix representing of a part of real time, with a certain reference message period at 2 different baud rates of 125 kbit/s and 500 kbit/s. A comprehensive communication behaviour table also needs to be done measuring changes for progressive manual adjustments of timer comparator values. In the acquired charts each new message entry is clearly visible, but its message CAN ID is not visible. From the CAN IDs it is possible to verify communication quality according to the designed time schedule.

since it was not possible to initiate the complete avionic system at a rate of 1 Mbit/s, it is recommended to focus on individual baud rate configurations for each segment of one transmitted bit, and also to use oscillators with more stable frequencies together with the use of shielded twisted pair.

Generally, the communication behaviour of the designed system is different at different baud rate and different time schedules. Thus, it is necessary to conduct detailed analysis for each baud rate and each time schedule and then evaluate the behaviour suitability.

In conclusion, the communication behaves as expected in the theoretical assumptions only with one baud rate and one value in the comparison timer register of a microcontroller. At different values of these parameters the system doesn't behave according to the time schedule as expected. To analyse the message entries more accurately a slightly more sophisticated data transmission algorithm for individual modules should be used and it is the aim of the future work.

REFERENCES

[1] W. Voss, "A Comprehensible Guide to Controller Area Network", pp. 25-145, vol. 2, Greenfield, Massachusetts, USA: Copperhill Technologies Corporation, 2005-2008.

[2] M. Stock, "CANaerospace", pp. 4-57, 1.7 revision, Stock Flight Systems, Germany, 2006.

[3] J. Bajer, R. Bystricky, R. Jalovecky, P. Janu, "Aircraft Sensors Signal Processing", Recent Advances in Mechatronics, vol. 1, pp. 73-78, 2009.

[4] D. Paret, "Multiplexed Networks for Embedded Systems - CAN, LIN, FlexRay, Safeby-Wire...", pp. 20-242, Wiley, 2007.

[5] N. Navet, F. Simonot-lion, "Automotive Embedded Systems Handbook (Industrial Information Technology)", pp. 312-475, CRC Press, 2009.

[6] ISO 11898-4: Road Vehicles - Controller Area Network (CAN), 2004.

[7] ISO 11898: In-vehicle networking, 2008.

[8] ISO 1000: SI Units and Recommendations for the Use of Their Multiples and of Certain Other Units, 1992.

[9] ISO 1151-1: Flight Dynamics - Concepts, Quantities and Symbols - Part 1: Aircraft Motion Relative to the Air, 1988. [10] ISO 1151-2: Flight Dynamics - Concepts, Quantities and Symbols - Part 2: Motions of the Aircraft and the Atmosphere Relative to the Earth, 1988.

[11] E. H. J. Pallett, "Aircraft Instruments and Integrated Systems" vol. 3, pp. 325-425, Pearson / Prentice Hall, 1992.

[12] R. Jalovecky, J. Bajer, "Development of the Aircraft Electronic System Using CAN with CANaerospace Protocol", International Conference on Military Technologies, pp. 360-365, 2009.

[13] R. Jalovecky, J. Bajer, "Systematic proposal of aircraft electronic system with CANaerospace protocol", Military Communications and Information Systems conference, pp. 4 - 7, 2009.

[14] P. Janu, R. Bystricky, J. Bajer, "Proposal of a Time-triggered Avionic Electrical Subsystem Using CANaerospase", International Conference on Military Technologies, vol.1, pp. 387-393, 2009.

[15] P. Janu, J. Bajer, "Practical Implementation of CANaerospace Protocol in LabVIEW Environment", Military Communications and Information Systems Conference, vol. 1, pp. 1 - 4, 2009.

[16] P. Janu, J. Bajer, "Time-triggered Communication in On-board Avionic Systems", Modern Safety Technologies in transportation, vol. 1, pp. 110-112, 2009.

[17] J. Bajer, P. Janu, R. Jalovecky, "Controller Area Network Based Onboard Data Acquisition System on Military Aircraft", Concepts and Implementation for Innovative Military Communications and Information Technologies, pp. 589-598, 2010.

[18] R. Bystricky, J. Bajer, P. Janu, "Proposal of low cost flight data recorder for ultralight aircraft", Modern Safety Technologies in Transportation, pp. 54-59, 2011.

[19] P. Janu, J. Parizek, "The canaerospace protocol contribution to the reliability and safety of the CAN", International Conference on Military Technologies, pp. 657-663, 2011.

[20] P. Janu, J. Bajer, "Dynamic time-slot assignment method applied on CAN with CANaerospace protocol during the aircraft phase of flight transitions", International Conference on Military Technologies, pp. 619-625, 2011.

[21] P. Janu, J. Parizek, "CAN Messages Transmission Diagnostic Analysis of Avionic System", Cybernetic Letters, no. 9, pp. 1-9, 2011.

Premysl JANU

University of Defence, Brno, 66210, Czech Republic

premysl.janu@unob.cz

The work presented in this paper has been supported by the Czech Republic Ministry of Defence (K206, K207 Department development program).

Digital Object Identifier 10.4316/AECE.2014.01013
COPYRIGHT 2014 Stefan cel Mare University of Suceava
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2014 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Janu, Premysl
Publication:Advances in Electrical and Computer Engineering
Date:Feb 1, 2014
Words:5325
Previous Article:Wake-on-a-Schedule: Energy-aware Communication in Wi-Fi Networks.
Next Article:Operation Characteristics Optimization of Low Power Three-Phase Asynchronous Motors.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters