Proceedings etc2016 -  - ebook

Proceedings etc2016 ebook

0,0
120,57 zł

Opis

For the second time the European Telemetry and Test Conference – etc2016 took place from 10 – 12 May 2016 in Nuremberg (Germany), in collaboration with the SENSOR+TEST 2016. Worldwide, there is no comparable platform to SENSOR+TEST / etc that offers such an intensive innovation dialog between suppliers of sensors, measuring and testing technology and users from all major industries. This cooperation provides in addition etc2016 exhibitors the opportunity to meet international customers from industry, science and research – from automotive industries, machinery constructions, electrical and energy industry, and of course aviation and space. The etc2016 spotlights the most recent innovations in methods, systems, and instrumentation from industry, researchers and laboratories all around the world. The European Telemetry and Test Conference offers original technical papers and innovation ideas in Test, Telemetry, Telecontrol, Instrumentation and Recording technologies for industrial, automotive, scientific, aerospace, space, naval and military applications.

Ebooka przeczytasz w aplikacjach Legimi lub dowolnej aplikacji obsługującej format:

EPUB

Liczba stron: 539




36th European Telemetry and Test Conference – etc2016

Bei diesem Band handelt es sich um den Kongressband der 36th European Telemetry and Test Conference – etc2016.

Dieser Band beinhaltet die Manuskripte zu den jeweiligen Vorträgen.

Für Form und Inhalt der Beiträge zeichnen sich die Autoren verantwortlich. Die AMA Service GmbH übernimmt keine Gewähr für die Richtigkeit, Genauigkeit und Vollständigkeit der Angaben sowie die Beachtung privater Rechte Dritter.

This volume covers the proceedings of the 36th European Telemetry and Test Conference – etc2016.

This volume comprises the manuscripts of the lectures.

The authors are responsible for form and content of the papers.

AMA Service GmbH accepts no responsibility for the correctness and completeness of the details and the consideration of private rights of third parties.

Foreword

Dear Telemetry Friends,

The European Society of Telemetry was pleased to welcome you back to Nuremberg! The 36th European Telemetry and Test Conference took place in cooperation with SENSOR+TEST, the measurement fair for the innovation dialog.

etc2016 was especially proud to host the 27th Symposium of the Society of Flight Test Engineers – European Chapter. Both our Conference and the Symposium took place in a joined area so that participants of both events could assist all presentations and exchange with each other on the latest telemetry technologies and their application in the newest flight test methods.

As part of the mission of the European Society of Telemetry to support technical growth and education in the fields of telemetry, etc2016 presented outstanding technical papers, short courses in the current telemetry hot topics, an exhibition with product innovations and a continuous interaction with the experts. Special sessions offered a platform for innovation with AIM2016 – Advance In-Flight Measurement –, but also for standardization with the ICTS General Session – International Consortium for Telemetry Spectrum –, the ETSC Open Meeting – European Telemetering Standardisation Committee and the MDL User Meeting – Measurement Description Language.

The technical papers are merged in these Conference Proceedings. Here you can find the latest and most promising hardware and software ideas for the telemetry solutions of tomorrow!

The ultimate success of the conference remains entirely dependent upon your continued patronage. So thank you very much for supporting etc2016!

We are always seeking ways to improve the European Telemetry and Test Conferences. Please contact us with ideas, critiques, suggestions, fill in the feedback forms or visit us on www.telemetry-europe.org.

We’re looking forward to meeting you!

Renaud Urli

President of the European Society of Telemetry

Index

Positioning & Timing

Chairmen: Pilar Vicaria Torralbo, Airbus Defence and Space, Getafe (Madrid) (Spain)

1.1 PTP version 3 in FTI

Øyvind Holmeide, OnTime Networks AS, Oslo (Norway); Markus Schmitzr, OnTime Networks LLC, Dallas (USA)

1.2 Nanosecond synchronous analog data acquisition over Precision Time Protocol

Matthias Braun, Milan Juranek, András Széll, Péter Szántó, Cruz Marín, Zodiac Data Systems GmbH, Bergisch Gladbach (Germany)

1.3 Evaluation of Radio Communication System for sharing location information between traffic objects

M. Kraetzig, K. Theuerkauf, L. Rauchhaupt, Institut für Automation und Kommunikation e.V. Magdeburg, Magdeburg; T. Speth, Technische Hochschule Ingolstadt, CARISSMA, Ingolstadt (Germany)

1.4 Testing GNSS receivers robustness against spoofing attempts

G. Boime, E. Sicsik-Paré, Spectracom SAS, Les Ulis (France); H. Sasaki, L. Perdue, Spectracom Corp., NY (USA)

1.5 Testing telemetry systems, which use GNSS satellite navigation systems Achieving reliable and accurate results with RF simulation of GNSS signals

Karen von Hünerbein, Werner Lange, Lange-Electronic GmbH, Gernlinden (Germany)

1.6 Research on the REALIZATION of passive TDOA in PCM/FM system

DAI Tao, XIE Nan, FENG Lei, WANG Yuan Dong, Institute of Electronic Engineering, Mianyang City, Sichuan Province (China)

Sensors &AIM2016

Chairmen: Fritz Boden, DLR, Göttingen (Germany)

2.1 Adaption of Fibre Optic Sensors and Data Processing Systems for Flight Test on a Bulldog Light Aircraft

N.J. Lawson, R.N.G. Correia, M. Partridge, S.E. Staines, S.W. James, J.E. Gautrey, R.P. Tatam, Cranfield University, Cranfield (U.K.)

2.2 Coupling of MEMS gyroscope application with wavelet analysis for detection of airframe oscillations in flight conditions

Jerzy Bakunowicz, Pawel Rzucidlo, Rzeszów University of Technology, Rezszów (Poland)

2.3 Developing a Novel Contactless Sensor for Helicopter Rotor State Measurements

Potito Cordisco, Edoardo Vigoni, Vicoter, Calolziocorte; Rui Liu, Emanuele Zappa, Politecnico di Milano, Department of Mechanical Engineering, Milano; Matteo Redaelli, Luca Riviello, Finmeccanica Helicopter Division, Varese; Alberto Rolando, Federico Rossi, Lorenzo Trainelli, Politecnico di Milano, Department of Aerospace Science and Engineering, Milano (Italy)

2.4 Non-Intrusive Ice Accretion Detection and Measurement System

Ricardo Entz, Airbus Group Innovations, München (Germany); Raphael de Andrade Jorge, University of Sao Paulo, Engineering School of Sao Carlos (Brazil)

2.5 Latest technology in piezoelectric vibration- and pressure sensors and their benefits for measurement

Stefan Meyer, PCB Synotech GmbH, Hückelhoven (Germany)

2.7 Fiber optic acoustic pressure sensor with high dynamic range and low noise

Markus J. Schmid, Mathias S. Müller, Bernd A. Kuhnle, fos4X GmbH, Munich; Michael W. Bauer, Reinhard Pongratz, AIRBUS GROUP Innovations, Taufkirchen; Andree Altmikus, Wobben Research and Development GmbH, Aurich (Germany)

Video & Data Management

Chairmen: Christian Herbepin, Airbus Helicopters, Marignane (France)

3.1 An Adaptable Constraints-based Metadata Description Language (MDL) System for Flight Test Instrumentation Configuration

Michael Neumann, Jessica Moore, The Boeing Company, Seattle, Washington; Satyaraj Pantham, Consultant, Seattle, Washington; Myron Moodie, Patrick Noonan, Austin Whittington, Southwest Research Institute®, San Antonio, Texas (USA)

3.2 Heterogeneous Acquisition systems managing

Jose Antonio Gonzalez Pastrana, Airbus Defence and Space, Getafe (Madrid) (Spain)

3.3 GUI Simulator for Automated Testing of Embedded Systems

Andy Walter, Florian Weber, macio GmbH, Karlsruhe; Torsten Rupp, macio GmbH, Kiel (Germany)

3.4 Achieving Dramatic Increases in T&E Effectiveness and Efficiency Leveraging Dynamic and Flexible M&S Tools

Nate McBee, Joshua Reicher, Analytical Graphics Inc. (AGI), Exton, PA (USA)

3.5 Concept for a modular flight test camera system

Arne Nowak, Michael Schöberl, Fraunhofer Institute for Integrated Circuits, Erlangen; Ingo Bebermeier, SEKAI Europe GmbH, Wedel (Germany)

Remote Data Acquisition

Chairmen: Diarmuid Corry, Continuity Consulting, Lusby (USA)

4.1 The Challenges of Data Acquisition in Harsh Remote Places

David Buckley, Curtiss-Wright Avionics & Electronics, Dublin (Ireland)

4.2 Multi-channel, robust measurement equipment for evaluation and certification testing as with the PC-24 from Pilatus Aircraft Ltd

Kai Gilbert, imc Test & Measurement GmbH, Friedrichsdorf (Germany)

4.3 High Performance Multi-Vendor Network Data Acquisition Platform

Domingos Rios, EMBRAER, Gavião Peixo (Brazil)

4.6 The research of smart test technology for launch system

Tieshan Feng, Li Daquan, Lan Kun, Beijing Institute of Astronautical, Fengtai Strict, Beijing (China)

Data Links

Chairmen: Nelson Leite, Instituto de Pesquisas e Ensaios em Voo, Sao Jose dos Campos (Brazil)

5.1 Telemetry, Command and Control of UAs in the U.S. National Airspace

Barry R. P. Jackson, Cahon Systems Inc, El Cajon CA 92020 (USA)

5.2 AN IEEE 802.11 BASED TELEMETRY SYSTEM FOR ULTRA LIGHT MACHINES FLIGHT TESTING

Alberto Rolando, Luca Minichini, Federico Rossi, Politecnico di Milano - Campus Bovisa, Milano (Italy)

5.3 Using LTE-Networks for UAS-Communication

Felix Maiwald, Axel Schulte, Universität der Bundeswehr München, Neubiberg (Germany)

5.4 Multi-Band (Ku, C, Wideband - Satcom, NarrowbandSatcom) Telemetry Test System for UAV Application

Murat Imay, TAI Turkish Aerospace Industries, Inc., Kazan-Ankara (Turkey)

5.5 Usability of LTE for Transmitting Radar Data from DLR’s Research Aircraft D0228-212

Stefan Baumgartner, Daniel Rosigkeit, Anton Nottensteiner, German Aerospace Center (DLR), Oberpfaffenhofen (Germany)

5.6 Onboard Flight Termination System with Electronic Safe&Arm Mechanism: A Rapid Solution for High Velocity Flight Vehicles

Muhittin Aktas, Celal Ertugrul, Celalettin Karakus, Roketsan Missiles Inc., Elmadag, Ankar (Turkey)

Ground & Onboard TLM systems

Chairmen: Günter Müller, Airbus Defence and Space, Manching (Germany)

6.1 Merging of Flight Test Data within the UMAT TDS

Tobias Paul, Tjorven Gerhard, ESG Elektroniksystem- und Logistik-GmbH, Fürstenfeldbruck (Germany)

6.2 MINI MOBILE TELEMETRY SYSTEM APPLICATION

Mahmut Kürsad Arpacioglu, Sedar Cora, Hakan Eser, TAI - Turkish Aerospace Industries, Kazan-Ankara (Turkey)

6.4 A Study on Implementation of Network Based Telemetry System Using Retransmission

Sooyeol Im, Chiho Hwang, Hwansuk Lee, Inho Choi, Agency for Defense Development, Daejeon (Korea)

Antennas & Tracking

Chairmen: Gilles Fréaud, AIRBUS France, Toulouse (France)

7.2 Telemetry Band C & S capabilities integrated for test range activities

Antonio Javier Mesa Fortun, Neves Seoane Vieira, Ana Corrales Sierra, National Institute for Aerospace Technology, Mazagon-Huelva (Spain)

7.3 Novel 11 meter SXK-Band Remote Sensing Ground Station Antenna

Gerbert Lagerweij, VERTEX Antennentechnik GmbH, Duisburg (Germany)

Wireless Data Acquisition

Chairmen: Sergio Penna, EMBRAER, Sao Jose dos Campos (Brazil)

8.1 Instrumentation for outer measurements in aeronautical applications

Alain Laurent, La Mesure Sur Mesure - LMSM, Aix-en-Provence (France)

8.2 Wireless Data Acquisition in Flight Test Networks

Diarmuid Collin, Curtiss-Wright Avionics & Electronics, Dublin (Ireland)

8.3 Ariane 5 Space Laucher Vehicle Equipment Bay Wireless Sensor Network Telemetry Subsystem with Smart Sensors

Hendra Kesuma, Tejas Ahobala, Steffen Paul, University of Bremen; Johannes Sebald, Airbus Defense & Space Bremen (Germany)

Data Processing

Chairmen: Pedro Rubio, Airbus Defence and Space, Getafe (Madrid) (Spain)

9.1 Remote monitoring and sophisticated analysis of status data from power generators

Martin Bussas, Philipp Baum, Trout GmbH, Kassel (Germany)

9.3 A frame based combining method for multiple receiver telemetry systems

Alparslan Mehmet Arasan, Celal Ertugrul, Roketsan A.S., Elmadag, Ankara (Turkey)

Key words

PTP VERSION 3 IN FTI?

Øyvind Holmeide1, Markus Schmitzr2

1 OnTime Networks AS, Oslo, Norway, [email protected]

2 OnTime Networks LLC, Dallas, USA, [email protected]

Abstract:

Time synchronization based on the Precision Time Protocol (PTP) according to the IEEE 1588 standard is a core building block for state-of-the-art high-performance Flight Test Instrumentation (FTI) systems. Two versions of the IEEE 1588 standard have been launched: PTP version 1 according to IEEE 1588™ - 2002 and PTP version 2 according to IEEE 1588™ - 2008. Now a new IEEE 1588™ working group has been established with the goal to launch a new revision of the IEEE 1588™ standard; i.e. PTP version 3.

The FTI industry is using both PTP version 1 and 2. The poor backward compatibility between PTP version 2 and 1 has been a big challenge for the FTI community. Backward compatibility with older PTP versions, new functions and to what extent PTP version 3 is relevant for the FTI industry are described and discussed in this paper.

The IEEE 1588 standards define several PTP profiles for various time synchronization usages in different industries. This paper also describes how PTP is used in FTI and also proposes a PTP profile definition for FTI including special time synchronization parameters/properties taken from the iNET standardization.

Keywords: IEEE 1588, PTP version 3, PTP profile, FTI, iNET.

Introduction

The FTI industry was one of the first industries that started to use PTP. This means that there is a large install base of FTI systems that are based on PTP version 1. The poor backward compatibility between PTP version 2 according to IEEE 1588™ - 2008 and PTP version 1 according to IEEE 1588™ - 2002 represented a major challenge for the FTI community since off-the-shelf PTP version 1 and 2 clocks could not be combined in the same network. A solution to this problem was launched by OnTime Networks in 2013 by the introduction of TC/SC Ethernet switches with PTP version translation support implemented according to the principles described in [1]. These TC/SC switches made it possible to combine PTP version 1 and 2 in the same network.

What about backward compatibility for new revision of the IEEE 1588™ standard?

A PTP version 3 working group, see [2] and [3], has been established and approved by IEEE. The working group shall ensure that the resulting standard has the highest degree of backward compatibility with previous editions of the IEEE 1588™ standard and all new features will be optional.

The scope of this working group is as follows:

Correct known technical and editorial errors

Better accuracy

Definition of an SNMP MIB

Security

Clarify the layering, interfaces and protocol of the standard

Several IEEE 1588 PTP profiles for different industries such as profiles for telecom, power systems (C37.238), PROFINET, etc. are defined. These PTP implementations are very different and should not be combined in the same network. The de-facto PTP implementation used in FTI is to a large extent based on the default PTP profile of the IEEE 1588™ - 2002 or IEEE 1588™ - 2008 standards, but also the evolving iNET standard specifies time synchronization properties that should be considered for such a PTP profile. This means first of all support for SNMP management of the network clocks and the possibility for generating alarms, i.e. SNMP trap, in case of synchronization loss and GMC hold-over capability in case of GPS loss.

The main PTP properties that are relevant for a FTI PTP profile for both IEEE 1588™ - 2002 or IEEE 1588™ - 2008 are as follows:

Clock modes

One-step vs. two step clocks

Media

Delay mechanism

Transport mechanism

Domain

Selection of Best Master Clock

PTP EPOCH

Sync interval

Delay_Req interval

Announce interval

PPS output

IRIG-B 002/122

Management

SNMP traps

GMC holdover

SC accuracy

SC time to synchronization

Abbreviations

BC

Boundary Clock

BMCA

Best Master Clock Algorithm

DST

Daylight Saving Time

E2E

End-to-End

FCS

Frame Check Sequence

FTI

Flight Test Instrumentation

GMC

Grand Master Clock

GUI

Graphical User Interface

IED

Intelligent Electronic Device

IP

Internet Protocol

IRIG

Inter-Range Instrumentation Group time codes

MAC

Medium Access Control

MC

Master Clock

OC

Ordinary Clock

P2P

Peer-two-Peer

PPM

Parts per Million

PPS

Pulse Per Second

RTOS

Real Time Operating System

SC

Slave Clock

SyncE

Synchronous Ethernet

TAI

Temps Atomique International

TC

Transparent Clock

TCP

Transmission Control Protocol

ToS

Type of Service

TZ

Time Zone

UDP

User Datagram Protocol

UTC

Coordinated Universal Time

PTP version 3

The working group formed to revise the IEEE 1588™ has established five sub-committees:

Architecture

High Accuracy

Upkeep

Management

Security

Architecture

The charter of the Architecture sub-committee is as follows:

“..clarify the layering, interfaces, and protocols of the standard, including the behaviour of systems that deploy different protocol options.”

Relevant topics for this sub-committee are:

State reduction

The FAULTY, PRE-MASTER and UNCALIBARTED states would become optional. This means that IEEE 802.1AS becomes a complaint profile and faster reconfiguration/synchronization can be achieved.

This change is first of all an implementation requirement that will not impact the observed node’s PTP protocol behaviour.

State reduction might be convenient for FTI SC if fast synchronization is required, see SC accuracy and time to synchronization section below.

Profile isolation

Multiple PTP profiles may exist on the same network with different BMCAs. The subcommittee suggests to use a transport specific attribute in the PTP header in order to define the PTP profile that the PTP packet belongs to in order to isolate the PTP profiles available on the network.

Only one PTP profile should be used in an FTI system. This function is not considered for FTI.

Port State Configuration

Port State Configuration means that a PTP port can be BMCA capable, SC only or GMC/MC only, where manual configuration is possible.

This is not considered to be relevant for FTI. FTI should allow SC only clock modes (DAUs), while all GMC candidates should support BMCA.

PTP domains

PTP domains in IEEE 1588™ - 2002 or IEEE 1588™ - 2008 do not interact. The subcommittee suggests that domains can share the same timing data in order to offer support for multiple simultaneous GMCs and multipath PTP for time synchronization redundancy purpose.

This is not considered to be relevant for FTI. FTI should only allow one PTP domain (i.e.: 0 – default).

High Accuracy

The charter of the High Accuracy subcommittee is as follows:

“The protocol enhances support for synchronization to better than 1 nanosecond.”

A proposal including support for SyncE for frequency synchronization at physical layer will be proposed. Frequency synchronization may be achieved through a different spanning tree than the spanning tree used for PTP. Calibration of each SC including compensation for all asymmetric components and cable delays will be part of the proposal. A “Golden Calibrator” for a given system may be required.

Data acquisition with sub-nanosecond or single digit nanoseconds accuracy in future FTI systems may be relevant. The High Accuracy section of PTP version 3 standard can then be relevant.

Upkeep

The charter of the Upkeep sub-committee is as follows:

“Incorporate official IEEE interpretations and other known errors or needed clarification into 1588-2008 in order to provide clean version as a basis for modifications of the current P1588 working group.”

“Once this is done serve as a “quality control” function for any modifications proposed by other committees to ensure freedom from inconsistencies and backward compatibility issues.”

This work includes clarification of the TC source address topic.

No major impact from the Upkeep section is expected for FTI.

Management

The charter of the Management sub-committee is as follows:

“The management sub-committee will consider the management of IEEE 1588 clocks, e.g. MIB, related management protocols (SNMP and native management protocol), and OAM mechanism.”

The Management sub-committee proposal is to create a single IEEE 1588 SNMP MIB. A mechanism to allow in-service monitoring of synchronization quality will also be proposed.

An IEEE 1588 SNMP MIB as well as extended support for monitoring the synchronization quality of the PTP clocks can be convenient for FTI. iNET standardization are targeting some of the same needs, but future FTI system can benefit from this proposal from the Management sub-committee.

Security

The charter of the Security sub-committee is as follows:

“To specify a security capability for PTP. This capability is expected to be optional.

The Security sub-committee considers technologies such as IPSec and MACSec. The requirements are based on IETF document: “draft-ietf-tictoc-security-requirements”.

FTI systems are in most cases considered as closed systems. Security related to PTP synchronization has not been an issue for FTI up to now.

PTP profile for FTI

The main PTP properties/parameters that are relevant for FTI are as follows:

Clock modes

IEEE 1588 defines the following PTP clock modes:

Grand Master Clock (GMC)

Ordinary Clock (OC)

Boundary Clock (BC)

Transparent Clock (TC)

Slave Clock (SC) only

An OC can either act as a GMC or a SC. If the OC wins the BMCA for the network, then the clock will be the GMC for the network. If not, then the clock may be passive or run as a SC. If the OC enters SC mode then the clock will discipline its local clock based on time updates from the chosen GMC of the network, while the clock will discipline its local clock based on its local time base (e.g. GPS) if the clock enters passive mode. More than one GMC or OC in the same network means better redundancy and robustness.

Ethernet switches and routers in a network can either support BC, TC, TC/SC or GMC clock modes. BC means that one port is in SC mode and the remaining ports are in MC mode. TC clock mode means that the local switch/router clock is used for calculating the switch/router residence time for each PTP event packet forwarded through the network element. This local clock may or may not be symphonized with the GMC clock of the network. The clock drift of a SC compared to the GMC in the network is calculated and compensated is the clock is synthonized, while both the clock drift and offset is calculated and compensated if the SC is synchronized with the GMC. A TC/SC switch contains also SC support. This means that the network element is both synthonized and synchronized with the GMC. A synthonized TC offers better accuracy compared to a TC with free running clock.

A SC only implementation means that the device only supports SC mode. This clock will discipline its local clock based on time updates from the chosen GMC of the network.

BCs are not used in today’s FTI systems. Only TC and TC/SC implementation are used. This is also valid for FTI systems based on the IEEE 1588™ - 2002 standard even though this standard does not specify TCs. The TC implementations used in FTI systems that are based on IEEE 1588™ - 2002 follows the proprietary principles presented and demonstrated by OnTime Networks at the IEEE 1588 conference in 2004, [4].

1-step vs. 2-step clock

IEEE 1588 specifies two types of clocks:

1-step clock

2-step clock

Figure 3 below shows the PTP packets used for performing time updates on a SC either based on 1-step clock or 2-step clock principles. The Sync and Delay_Req packets are PTP event packets, while the Follow_Up and Delay_Resp packets are general packets.

A one-step clock implementation is based on including the precise egress timestamp, t1, from the GMC into the Sync packet payload, while a corresponding two-step clock implementation is based on sending this timestamp in a Follow_Up packet that follows the Sync packet.

A one-step clock implementation must generate and update the Sync packet with the precise egress timestamp and perform and update the packet FCS in hardware. No Follow_up packet is required if one-step clocks are used.

Only 2-step clock implementations are used in FTI for both IEEE 1588™ - 2002 and in IEEE 1588™ - 2008.

Figure 3, 1 -step vs- 2-step clock

Media

IEEE 1588 can be used for several media. Wired Ethernet is by far the most used communication technology used for IEEE 1588, where both copper and fiber and any Ethernet speeds can be used. The IEEE 1588™ - 2002 or in IEEE 1588™ - 2008 standards do not specify that the duplex connectivity must be full duplex, but most PTP profiles do specify this. Note that half duplex connectivity and Ethernet PHYs/MACs supporting IEEE 1588 might not work properly.

Only full duplex connectivity is used in FTI.

Delay mechanism

The delay mechanism defined in IEEE 1588™ - 2002 is used to calculate the propagation delay between a given SC and the GMC. This principle is shown in Figure 3 above. A normal time update is based on the egress timestamp generated by the GMC when the Sync is sent from the GMC, t1, and the ingress timestamp of the same packet is generated by the SC when this packet is received on the SC, t2. The SC can also send event packets. The Delay_Req packet originates from a SC and this packet is used for the purpose of calculating the propagation delay between the GMC and the given SC. An egress timestamp is generated when this packet is sent from the SC, t3, and a corresponding ingress timestamp, t4, is generated on the GMC when the packet is received on this PTP clock.

The propagation delay is calculated based on the following formula:

The above delay mechanism technique is in IEEE 1588™ - 2008 standard referred to as End-to-End (E2E).

The IEEE 1588™ - 2008 standard also introduced a new delay mechanism technique called Peer-to-Peer (P2P). P2P is based on the same principle as E2E except the propagation delay calculation performed by a PTP clock is only performed for the link partners of the PTP clock. A set of three new PTP packets are defined for P2P:

PATH_DELAY_REQUEST

PATH_DELAY_RESP

PATH_DELAY_RESP_FOLLOW_UP

(in case of two-step clock)

A P2P clock must update the PTP packet (Sync packets in case of one-step and Follow_Up packets in case of two-step) with the peer-delay to the PTP clock the packet is sent to. For a TC switch this means that the switch must update the PTP packet with both the switch residence time and the propagation delay of the link where the SYNC packet is received if the switch is enabled for P2P.

Only E2E is used as delay mechanism in FTI for both IEEE 1588™ - 2002 and in IEEE 1588™ - 2008.

Transport mechanism

IEEE 1588 defines several transport mechanisms for PTP. PTP can be based on unicast communication (telecom) or multicast (most other PTP profiles), PTP above layer 2 (power stations) or UDP/IP (default profile).

FTI is based on:

PTP over UDP/IP

Multicast with destination IP address: 224.0.1.129

UDP destination port number 319

(event packets) and 320 (general packets)

This is valid for both IEEE 1588™ - 2002 and IEEE 1588™ - 2008.

PTP domain

IEEE 1588 defines several domains for PTP. This means that several time domains can exist in the same network. Separate MC selections will be done in a network where two or more time domains exist. Default domain is 0.

FTI only uses the default domain for both IEEE 1588™ - 2002 and in IEEE 1588™ - 2008.

Selection of Best Master Clock

The default BMCA as defined in IEEE 1588™ - 2002 or IEEE 1588™ - 2008, are used in today’s FTI systems. Simpler FTI systems that are based on a single GMC without any BMCA support do also exits, but this is not recommendable since such solutions do not offer redundancy and may also represent IEEE 1588 interoperability issues when GMC and BMCA capable clocks later are installed.

PTP EPOCH

PTP is based on using TAI as its epoch. That means the number of seconds elapsed since January 1st 1970. The difference between this epoch and UTC is the accumulated number of leap seconds introduced since January 1st 1970. The current number of leap seconds is provided by the PTP GMC by the value of the currentUTCOffset parameter.

26 leap seconds have been inserted since 1970, the most recent on June 30, 2015 at 23:59:60 UTC.

The SCs in the network are responsible for converting TAI to UTC if such time representation is required and/or to compensate the time for DST or local TZ. This is valid for all for all PTP profiles.

Sync interval

The minimum interval between Sync packets was reduced in IEEE 1588™ - 2008 standard compared to IEEE 1588™ - 2002 standard. Legal range for the Sync interval is typical defined in the given PTP profile. The accuracy can be improved if the Sync interval is small, depending on the oscillator choice and the temperature variation at the SCs.

Most FTI systems are based on one (1) second Sync interval. A Sync interval range of [1, 2] seconds for IEEE 1588™ - 2002 and [0.125.. 2] seconds for IEEE 1588™ - 2008 with one (1) second as default Sync interval for IEEE 1588™ - 2002 and 0.125ms for IEEE 1588™ - 2008 are proposed for FTI.

Delay_Req interval

The minimum Delay_Req interval for IEEE 1588™ - 2002 is 60 seconds with randomization. Randomization is introduced in order to avoid that the SCs send Delay_Reqs at the same time. This interval is controlled by two parameters on the SC: PTP_DELAY_REQ_INTERVAL (30 seconds) and PTP_SYNC_INTERVAL_TIMEOUT (2^(Sync interval)).

This parameter is controlled by the GMC and not each SC in the IEEE 1588™ - 2008 standard. The Delay_Req interval parameter is propagated to the SCs in the Delay_Resp packets originating from the GMC. The legal range for this parameter for IEEE 1588™ - 2008 is [Sync interval, 32 x Sync_interval] seconds with randomization.

Announce interval

The Announce packet was introduced in IEEE 1588™ - 2008 standard. Announce packets are used for BMCA. Similar parameters found in the Sync packets are used for the BMCA for IEEE 1588™ - 2002 systems. The Announce interval is typical two times the Sync interval, and this principle should also be used for FTI systems.

PPS output

The IEEE 1588 standards do not specify that a PTP clock shall have a PPS output interface, but this is highly recommended for time synchronization systems. FTI is not an exception. A PPS output is therefore proposed as a mandatory requirement for a PTP profile for FTI for both IEEE 1588™ - 2002 and IEEE 1588™ - 2008.

IRIG-B output

IRIG-B, both IRIG-B 002 (DC) and IRIG-B 122 (AM), has traditionally been used in FTI context. Compatibility between PTP and IRIGB can be achieved if some of the PTP clocks in an FTI system can provide IRIG-B output signals. IRIG-B should be defined as a mandatory function for FTI for both IEEE 1588™ - 2002 and IEEE 1588™ - 2008 for GMC and optional for TC/SC.

Management

Chapter 15 of IEEE 1588™ - 2008 specifies IEEE 1588 management. IEEE1588 management packets are used for reading all possible PTP parameters and also for setting all writeable PTP parameters.

The same PTP data set parameters may also be available via SNMP private MIBs.

The PTP management protocol is particular useful for verification of synchronization lock of SCs in the PTP network. The OffsetFromMaster parameter can be monitored in order to verify that a given SC is synchronized with GMC of the network and how accurate the SC is. The PTPv2Browser MS Windows tool from OnTime Networks that supports the PTP management protocol. Figure 2 shows the PTPv2Browser GUI of the OffsetFromMaster variable for two SCs in a PTP network. Monitoring the OffsetFromMaster parameter is an alternative technique to comparing PPS output signals from the GMC and SC on an oscilloscope.

The iNET standard specifies a set of time synchronization parameters available via MDL or the iNET SNMP MIB, where e.g. PTP version can be set and PTP state can be read

PTP management according IEEE 1588™ - 2008 should be defined as an optional management protocol for FTI, while management via iNET MDL and SMNP according to the iNET TmNS MIB is mandatory.

Figure 2, PTP Browser GUI, monitoring the OffsetFromMaster parameter of two SCs

SNMP traps

The iNET TmNS MIB specifies several SNMP traps that can be sent to an SNMP host station in order to immediately detect any time synchronization problems. The following traps are defined:

timeLockLostNotificationBranch Trap is sent from the PTP GMC if synchronization lock from its time base is lost

ieee 1588 Max Offset From Master Notification Branch Trap is sent from SC if the OffsetFromMaster parameter exceeds pre-defined thresholds

ieee1588MaxJitterNotificationBranch Trap is sent from the PTP clock if the measured jitter of the local clock exceeds pre-defined thresholds

GMC hold-over

The iNET standard specifies that an iNET GMC must offer a clock hold-over capability of minimum 0.1ppm in order to ensure that clock synchronization for the whole FTI system is kept when GPS lock is lost or when GPC lock is established after a period of no GPS lock.

0.1ppm means 100ns drift over one seconds or a maximum of 360us during one hour. This worst case drift is, however, calculated over the whole temperature range that the FTI GMC must support: i.e.: [-40 ..185]˚F / [-40 ..85]˚C.

Figure 3 shows that the clock drift for the CM1608F0 GMC with OCXO as oscillator from OnTime Networks after GPS lock is lost, is less than 320µs over a time period of 60 minutes when the temperature is cycled from: -40˚F / 40˚C to 203˚F/95˚C. This means clock holdover capability better than 0.1ppm.

Figure 3, CM1608F0-AERO-GMC, clock drift

Clock drift of an oscillator when the temperature variation is less than e.g. 18˚F / 10˚C for a one hour period will only be a few percentage of the clock drift of the whole temperature range. That means less than 10us drift during one hour.

The GMC is supposed to stay in MASTER state when GPS lock again is found. The GMC will then start to discipline its local clock based on the new PPS input from the GPS based on its clock servo algorithm. The SCs will correspondingly discipline their local clocks based on clock updates from the GMC that gradually will be based on GPS clock. How fast the PTP clocks are disciplined to GPS time after a GPS lock period depends on the drift amount and clock servo implementations on the GMC and SCs.

SC accuracy and time to synchronization

iNET specifies that a SC shall not drift more than 1ppm from the GMC of the network, and that time to synchronization must be less than 1 seconds for airborne systems and 3 seconds for ground installations after the GMC becomes available.

This iNET requirement requires that the Sync interval is as small as possible This is why the proposed Sync interval is 1s for IEEE 1588™ - 2002 and 0.125ms for IEEE 1588™ - 2008.

PTP profile for FTI

Table 1 below summarizes the proposed PTP profile for FTI:

(*) Proprietary TC implementation

Table 1

Conclusion

Backward compatibility between the new emerging PTP revision, PTP version 3, and PTP version 2 will be kept. This means that PTP version 2 and 3 can be combined in the same network. The new functions that are planned in PTP version 3 will be optional. These new functions are not expected to be crucial for the FTI industry. PTP version 2 is expected to be the preferred PTP version for FTI for the foreseeable future, but new PTP version 3 functions can be considered for FTI application with high accuracy and/or security requirements.

This paper also describes the main PTP properties/parameters that are relevant for FTI and proposes a PTP profile definition for FTI based on the PTP default profile for both IEEE 1588™ - 2002 and IEEE 1588™ - 2008 in addition to time synchronization requirements defined in the iNET standard.

Reference

[1] D. Lefevre1, N. Cranley, Ø. Holmeide, “PTPv1 and PTPv2 translation in FTI systems”, ITC2013 Las Vegas – USA.

[2] Silvana Rodrigues, “New IEEE 1588 Revision”, WSTS 2014, San Jose

[3] Doug Arnold, “IEEE 1588 Working Group Update”, WSTS 2015, San Jose

[4] S. Nylund and Ø. Holmeide, “IEEE1588 Ethernet switch transparency – No need for Boundary Clocks!”, IEEE1588 conference, 2004.

Nanosecond Synchronous Analog Data Acquisition over Precision Time Protocol

Matthias Braun, Milan Juranek, András Széll, Péter Szántó, Dr. Cruz Marín

Zodiac Data Systems GmbH, Friedrich-Ebert-Str. 75, 51429 Bergisch Gladbach, Germany

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]

Abstract

This paper describes an implementation of the Precision Time Protocol – IEEE™ 1588-2002 and IEEE™ 1588-2008 – in order to reach maximum accuracy in time synchronization as a requirement for simultaneous analog data sampling.

Exact cross-correlation calculation between various measurements calls for a very small phase error margin between the sampled signals. Besides, there is an increasing need to synchronize the analog sampling carried out at different places without utilizing additional synchronization connections between different devices.

Nowadays, Ethernet is universally used and therefore present almost everywhere. Data acquisition systems typically deliver their data via networks. For time synchronization, the Precision Time Protocol (IEEE1588™) is basically a mandate. This protocol provides the high accuracy required for synchronous and simultaneous analog sampling.

The performance evaluation of the present implementation shows that an absolute time synchronization better than 10 nanoseconds can be achieved between two given data acquisition systems. Furthermore, this paper elaborates on how the analog sampling can be synchronized to the absolute time with this same accuracy.

Key words: IEEE1588, Time Synchronization, Analog Data Acquisition, Synchronous and Simultaneous Analog Sampling

Introduction

In flight test instrumentation, reducing and simplifying wiring is a continuous effort. One way to achieve this goal is to use distributed data acquisition systems, where connecting only power and some serial digital communication lines (most commonly Ethernet technology) obviates the need of long cabling for all sensors over long distances. Beyond data transfer, Ethernet is used for the distribution of absolute time for coherent time stamping, enabling more and more accepted methods to guarantee synchronous analog sampling between multiple data acquisition units. Because no additional hardware or software components are required, the method described in the following, which is based on the standard Precision Time Protocol (PTP), is data acquisition hardware manufacturer independent.

Fig. 1 Data Acquisition Unit

Analog Synchronization

In order to be able to correlate analog data from different acquisition systems it is necessary to synchronize the time and the analog sampling points in multiple systems to each other. Using the PTP protocol is one approach conducive to synchronizing the acquisition systems to a GPS based PTP time server. To avoid the need of a digital resampling of the analog data the target is to ensure that the real analog samples are taken at the same time by means of synchronizing both the frequency and phase of the sampling clocks.

The first step is to establish a precise absolute time base for the Data Acquisition Devices based on the PTP Synchronization Protocol. To synchronize the sampling clock frequency of all analog to digital converters (ADCs) to this absolute time base, the digital frequency generator devices have to be tuned in a second step. This tuning can only be done in very small steps in order to avoid jitter in the analog sampling – so the generated absolute time from the first step must be jitter-free as much as possible. In the last step the same phase of the sampling has to be guaranteed. To be able to sample the analog signals simultaneously in multiple systems it is necessary to take into account the delays effective along the entire signal path, on which a signal propagates from the input connector to the place where digital sampling takes place, including the pass through amplifiers and filters – the analog sampling needs to be delayed accordingly.

On one hand it is possible to design digital filters with arbitrary delays so that the total propagation delay of the ADCs and digital filters is typically an integer number of samples. But on the other hand, when it is not possible, the sampling signals shall be adjusted to compensate also fractions of the delays.

With this method it is theoretically feasible to phase correlate the acquired signals even if different types of acquisition hardware components are used. To simplify the analysis process of finding corresponding samples based on the timestamps included in data streams, the start of the data packets can be synchronized to the second’s change, which is only doable when using integer sampling rates.

The accuracy of sampling synchronization depends on the following factors:

The stability of the reference clock.

The accuracy of the absolute time synchronization in the data acquisition unit.

The resolution of the sampling frequency control.

The accuracy of the compensation of the analog and digital delays of the digitalization process.

The jitter of the sampling clock.

Recording Format

This implementation uses the IRIG 106 Chapter 10 data format [1] for its recordings. In this data format (see Fig. 2) all acquired data is timestamped with a free running relative time counter. While every data acquisition unit has its own relative time counter and their values don’t necessarily equal each other, it is necessary to convert all timestamps to one time domain to correlate two analog channels from different systems. The following steps are mandatory to convert the time domain of recording 2 to the time domain of recording 1:

In this example the analog data was created simultaneously.

Fig. 2 Packet structure of two IRIG 106 CHAPTER 10 recordings.

Precision Time Synchronization Protocol

To synchronize computer clocks over a given network, a protocol called 'Precision Time Synchronization Protocol' exists. Today two versions are available. The first version was published in 2002, and therefore it is named 'IEEE Std 1588™-2002, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems'. Version 2 was introduced in 2008, and it is known as 'IEEE Std 1588™-2008, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems'. It is not backwards compatible and is designed to improve the precision and robustness of the time synchronization while achieving an accuracy better than 1 nanosecond.

In a PTP network domain, different types of clocks can coexist. They are called 'Ordinary Clocks', 'Boundary Clocks' and 'Transparent Clocks'. An 'Ordinary Clock' is a device that uses a single network connection for time synchronization. It can act as a master or as a slave clock. A 'Master Clock' sends out timing information for a 'Slave Clock' to get in sync with it. A 'Boundary Clock' uses multiple network connections and is used to synchronize several network segments. The third type of clock is called 'Transparent Clock'. This one is introduced in IEEE™1588-2008. 'Transparent Clocks' convey PTP messages and modify the timing information with the time slice the PTP messages need to pass through the network node. This allows better compensation of message delays.

In a PTP domain, more than one master clock can be present. By evaluating the 'Announce Messages' every master clock generates, a 'Grand Master Clock' also known as GMC, is elected by the 'Best Master Clock Algorithm' (BMC). The GMC is the root timing reference which transmits synchronization information for all other clocks in the PTP network. The slave clocks synchronize to this 'Grand Master Clock' by exchanging different timing messages.

The GMC periodically broadcasts 'Sync Messages' over the network to let the slave clocks know about its timing information. Therefore, the instant of time when the 'Sync Message' leaves the GMC hardware has to be embedded into this message. This is called a one-step synchronization and requires hardware processing for highest accuracy. Master clocks without such hardware follow a two-step synchronization protocol. Here the 'Sync Message' contains an estimated timestamp, but in addition, a separate 'Follow_Up Message' is broadcasted with the accurate timestamp of the instant the 'Sync Message' leaves the GMC. For the implementation of the delay compensation, the calculation of the predicted propagation time of the PTP message transfer over the wire ('Mean Path Delay') is required. Two more PTP messages have to be sent over the network: The slave clock sends out a 'Delay_Req Message' for which the GMC notes the timestamp when it arrives and after that sends back a 'Delay_Resp Message' containing this timestamp. For an exact description of how this message exchange happens please have a look at: 'IEEE1588™-2008, 11.3 Delay request-response mechanism' [3].

The PTP messages are divided into 'General Messages' and 'Event Messages'. 'General Messages' provide more general information whereas 'Event Messages' are time critical and provide timing information for calculations in the PTP stack. Therefore they have to be timestamped. This can be done in software or in hardware. While software timestamping is not deterministic, hardware timestamping allows a much more precise accuracy in timing information for the offset calculations in the PTP stack.

In order to timestamp arriving and departing 'Event Messages', the hardware layer needs to detect these as close as possible to the physical wire using the physical interface chip also known as PHY. Once a PTP Ethernet packet is identified as an 'Event Message', the PHY core stores the value of the PHY internal global counter and the ID of the PTP packet into specific registers. Also, it informs the CPU respectively the kernel PHY driver that such an event happened. As shown in Figure 3, a '100MHz Relative Time Counter' (rtc100) is implemented in every Data Acquisition Unit which is driven by a 'Controlled Oscillator' (CXO). To allow correct calculations of the value of the timestamp in nanoseconds when an 'Event Message' arrives or departs, the PHY of the given hardware is programmed to continuously trigger an impulse to the FPGA to capture the actual '100MHz Relative Time Counter' value and match them against the PHY internal global time counter. The PTP stack can now grab the timestamp information from the PHY driver for further calculations. In order to sync a Slave Clock to a given Grand Master Clock, the Time Processing Unit has to be informed by the PTP stack of the elapsed nanoseconds since the start of the PTP epoch (January, 1st 1970 00:00:00 UTC) at a given rtc100 counter value. This timestamp is the instant of time when the 'Sync Message' leaves the GMC (also known as the 'Precise Origin Timestamp'), compensated with the 'Mean Path Delay'. For further details refer to 'IEEE1588™-2008, 11.3 Delay request-response mechanism' [3].

Fig. 3 PTP Message Flow and Timestamping in a Data Acquisition Unit

Time Processing Unit

The time synchronization subsystem or Time Processing Unit (TPU) supports synchronization to several source types including PTP. For any of these time sources, pulse-per-second (PPS) may also be connected to increase time precision. High precision (better than 100 ns) time synchronization to most sources is possible either with the PPS pulses or using long-term filtering in order to reduce measurement noise. Longer filtering (in the range of minutes, up to half an hour) is sensible only if proper time keeping is possible by means of using a stable oscillator. Otherwise, even though measurement noise is reduced by long-term averages or filtered values, temperature changes and other factors affecting the internal clock will introduce midterm and long-term frequency deviations, degrading the performance of any filters applied to the input source.

The TPU is a time source itself. There is a trade-off between the filtering/tuning parameters: By applying strong filters on the input time source, the clock output will appear more stable and less jittery (assuming an oscillator with good short-term stability), but it will lock in and follow frequency drifts more slowly, resulting in large temporary offset errors against the source.

Due to the different characteristics of the external clock sources, the TPU uses clock source specific filtering. For some sources it is possible to record the raw, unfiltered input timestamps (for error detection) or filtered ones. Filtering, outlier detection and averaging of the input signals is necessary to reduce noise and sampling errors.

Even the best algorithms fail to perform well if the underlying hardware architecture doesn`t allow to properly sample the incoming timestamps and to keep the internal clock in sync with the external source. The base clock used in the TPU is either a voltage controlled oscillator (VCXO) or an oven controlled oscillator (OCXO) with better than 10 ppb stability. The VCXO has frequency fluctuations in the range of 50 ns/sec (50 ppb) even under stable temperature conditions. This is partly due to the imprecision of the crystal and partly due to the higher tuning range of the VCXO, thus it is more susceptible to minor tuning voltage noises (of mV level). In order to synchronize within 30 ns to the master clock, the presented synchronization method uses an OCXO. Under stable ideal conditions this setup can be finetuned to be within 1-2 nanoseconds from the reference clock.

Fig. 4 Oscillators compared: Allan deviation of a TPU synchronized over PTP or PPS featuring an OCXO (solid lines) or VCXO (dashed)

Time stamps in the TPU are generated at 200 MHz resolution for PPS source and at 100 MHz for PTP sources (the rtc100 counter), meaning an inherent time stamping jitter of 5-10 ns. In case of PTP, the actual timing inaccuracy resulting from the finite resolution of the Ethernet PHY’s time stamps is larger if the clock source is connected via 100 Mbit Ethernet, as the 25 MHz frequency used for data transmission means 40 ns resolution at best (in contrast to the 1 Gbit Ethernet’s 125 MHz clock and 8 ns resolution). To reach the best analog synchronization performance, a Gbit Ethernet was used for the present work

Fig. 5 Effect of Ethernet speed and oscillator type on PPS/PTP timestamping jitter and frequency drift

In Figure 4 the performance of the voltage controlled oscillator is compared to the oven controlled, temperature-stabilized oscillator. In this Allan deviation plot it is apparent that the short-term PTP precision is below the accuracy of PPS input due to the 40 ns resolution, but for longer averages (in the range of 103 seconds) their variances match, and the OCXO based solution is one order of magnitude better than the other system utilizing a VCXO. The VCXO frequency stability already deteriorates in the range of 100 seconds mostly due to temperature changes, as seen in Figure 5.

During the initial phase of the synchronization the oscillator is tuned to match the short-term averaged frequency of the GMC (3-5 seconds) and the offset is compensated with period time modification (as if the seconds are a few extra microseconds longer or shorter than 106). Once the oscillator frequency and offset errors are within bounds, only oscillator frequency tuning is applied afterwards. Synchronous analog sampling begins only in this second phase. The filter coefficients gradually change to reduce tuning the jitter as the observed offset and frequency error gets smaller. Offset errors are reduced by dithering (temporarily mistuning the frequency similarly to how one car keeps distance from the other just by minor accelerations and decelerations).

After successful synchronization the synchronized internal RTC clock is recorded into IRIG 106-09 Chapter 10 time packets and sent out to all other modules taking part in the data acquisition. The time packets contain the UTC time recorded at the given relative recording time, which is by default time stamped with 100 ns resolution. Later Chapter 10 extensions will increase the precision to nanoseconds.

Sampling Clock Generation

In a distributed system it is often not possible for the analog data acquisition units to communicate with each other, only their clocks can be synchronized. A 1 Hz 'analog frame signal' populated from the time synchronization subsystem via a dedicated clock pulse distribution network to the analog sub-systems is used to ensure simultaneous sampling.

The analog sampling clock is derived from the time subsystem’s 100 MHz clock with a digital synthesizer. This clock value is an integer multiple of the analog sampling clock rate only in a limited set of frequencies, so in most cases it is necessary to fine-tune the synthesizer by means of a PI controller (proportional-integral controller) to ensure that the 1 Hz analog frame signals match the PPS signal of the TPU. The regulation of the PI controller can be seen in Figure 6. In this case an Analog Master Clock of 19.1979 MHz will result in a standard deviation of 3.519 ns. The time offset is measured between the falling edge of the analog frame signal C3 (which is an active low signal) and the rising edge of the PPS out signal C1.

Fig. 6 Deviation measurement between the PPS output ands the low active Analog Frame

Properly compensating signal delays in each input channel will allow a correlation between the latter even if their sampling rates are different.

 Evaluation of Results

Figure 7 shows the Data Acquisition Unit’s synchronization to a Grand Master Clock. The synchronization was carried out via a dedicated 100 Mbit network connection, the recorded data was transferred over a separate Ethernet interface.

Fig. 7 IEEE1588-2008 direct synchronization against Grand Master Clock: offset error distribution

There are a multitude of possible error/jitter sources, among others:

Frequency drifts due to temperature changes

Noise/jitter in the signal (on PTP the network traffic, the carrier/PHY buffering jitter and performance of other network components; delay measurement issues)

Time stamping inaccuracies caused by finite time stamping resolution (‘time domain quantization errors’)

Analog sampling clock synchronization against internal (synchronized) clock

In suboptimal cases a lot depends on the input filtering. It is necessary to filter PTP Sync message timestamps and delay measurements for outliers; the tuning coefficients are modified if incoming timestamp jitter/offset is above threshold. Under ideal real world conditions (proper PTP-aware network devices, analog recorders are on the same subnode/switch) some of the described effects are marginal, and others are mitigated by the filtering capabilities of the tuning algorithm. This way, a 30 ns synchronization precision can be achieved against the GMC. In case of a direct connection an even better 5-10 ns precision was measured between two modules synchronizing against the same GMC.

Figure 8 shows the measurement picture of an oscilloscope sampling the 1 PPS signals of the two Data Acquisition Units (C2 and C3) and the Grand Master Clock (C1). The trend-line F1 shows the delta delay of C2 against C3 with 100 measurements per division in the direction of the x axis. The time base in y axis is 5 nanoseconds per division. A jitter of the delta delay of ±5 ns is measured. For this measurement 3711 samples were taken at a measurement rate of 1 Hz. Within this one hour of measurement a mean delta delay of the 1 PPS signals of the two acquisition units of 7.65871 ns is achieved with a standard deviation of 2.17535 ns.

Fig. 8 1 PPS Offset between GMC and two synchronized Data Acquisition Units

Conclusion

It was demonstrated that with precise onboard oscillators and a good quality time source a distributed data acquisition system can achieve synchronous analog sampling accuracy of the 10 ns range by the means of the IEEE™1588-2008 Precision Clock Synchronization Protocol.

The precise synchronization is not instantaneous. In the current implementation it takes up to 5 minutes to achieve stable sync but there are several possibilities to reduce the time the different filters need for settling.

It should be noted that even though module-to-module the analog sampling can be extremely synchronous, this remains so only as long as the same algorithm with same parameters is used for synchronization. E.g. if one of the modules uses PID controller for PTP synchronization and the other uses a Kalman filter based approach [4] or a very simple FIR filter (e.g. present in the earlier IEEE™1588-2002 implementation), these will result in very different responses to the GMC clock changes and a 10 ns analog sampling precision as shown in Fig. 9, may become impossible in a heterogeneous recording environment.

Fig. 9 Phase correlated PTP synchronized analog channels of two Data Acquisition Units

There are possible improvements over the basic implementations of the PTP utilizing Synchronous Ethernet (e.g. White Rabbit [5]) that target the sub-nanosecond synchronization range. These systems use expensive hardware and guarantee that the Ethernet clock frequency is the same throughout the network, removing some noise sources.

References

[1] Telemetry Standards, IRIG Standard 106-13 (Part1), Chapter10, http://irig106.org/docs/106-13/chapter10.pdf

[2] IEEE Std 1588™-2002, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, Print: ISBN 0-7381-3369-8, SH95023; PDF: ISBN 0-7381-3370-1, SS95023

[3] IEEE Std 1588™-2008, IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, Print: ISBN 978-0-7381-5401-5, STDPD95773; PDF: ISBN 978-0-7381-5400-8, STD95773

[4] G. Giorgi, C. Narduzzi, Performance analysis of Kalman filter-based clock synchronization in IEEE 1588 networks, International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication 2009, doi: 10.1 109/ISPCS.2009.5340221

[5] P. Moreira, J. Serrano, T. Wlostowski, P. Loschmidt, G. Gaderer, White Rabbit: Sub-Nanosecond Timing Distribution over Ethernet, International IEEE Symposium on Precision Clock Synchronization for Measurement, Control and Communication 2009, doi: 10.1 109/ISPCS.2009.5340196

Evaluation of Radio Communication System for sharing location information between traffic objects

M. Kraetzig1, T. Speth2, K. Theuerkauf1, L. Rauchhaupt1

11nstitut für Automation und Kommunikation e.V. Magdeburg, Werner-Heisenberg-Str. 1, 39106 Magdeburg, Germany, [email protected]

2Technische Hochschule Ingolstadt, CARISSMA, Paradeplatz 13, 85049 Ingolstadt, Germany, [email protected]

Abstract:

Dedicated short range communication (DSRC) or radio systems for intelligent transport systems (ITS) should be used for transmission of position information between dynamic traffic objects. The position information shall be used to improve the accuracy of localisation of traffic objects. Therefore the safety in road traffic is increased by avoiding dangerous situations and accidents. Due to relative movement of traffic objects the position data becomes outdated, the longer it takes to transmit the information via ITS radio system. For that reason, the transmission time of ITS radio system shall provide an input to correct the transmitted position data at the receiver.

Keywords: Intelligent Transport Systems, System analysis, Transmission characteristics, Timing analysis, Performance analysis, Performance characteristics, Reliability analysis, Reliability evaluation

1. INTRODUCTION

This paper starts with a description of the application scenario of time critical communication between intelligent transport systems (ITS). Thereafter a model is introduced from which relevant characteristic parameters are derived which are used to assess reliability. The test method to evaluate the performance of ITS radio system is also part of the report. The main part of the paper is the performance assessment of radio system for intelligent transport systems (ITS). The focus is the assessment of time and error behaviour. Furthermore, the effects of influencing parameters will be shown by measurements results. At the end of the paper the results of evaluation will be discussed.

2. APPLICATION SCENARIO

Applications for integral vehicle safety as well as some advanced driver assistance systems (ADASs) benefit from precisely determination of relative positions between dynamic traffic objects. Especially the intervehicular exchange of position and dynamic data offers a new potential for these systems, e.g. vehicle-interactive applications [1