Dt

Ja

b

a

ARA

KSGDs

1

ocmtlaaEnTcJcNdatamU[tt

0h

Optik 125 (2014) 1937– 1941

Contents lists available at ScienceDirect

Optik

jou rn al homepage: www.elsev ier .de / i j leo

esign of data communication and management system for groundest and verification devices of space laser communication

ianmin Wanga,∗, Fucai Lib, Yudong Liua, Yu Fanga

Institute of Quantum Electronics, School of Electronics Engineering and Computer Science, Peking University, Beijing 100871, ChinaThe 28th Research Institute of China Electronics Technology Group Corporation, Nanjng 210007, China

r t i c l e i n f o

rticle history:eceived 5 May 2013ccepted 28 September 2013

a b s t r a c t

Verification of a space laser communication system’s parts or of component-level, terminal-level, andsystem-level performance using ground test and verification devices on the ground before launch isvital. In this paper, a data communication and management system is proposed, which is an important

eywords:pace laser communicationround test and verification devicesata communication and management

part of the ground test and verification devices system and manages the test process and impacts on themeasurement results directly. We improved the existing hardware buses to make up the hardware part,and also designed the software part. Several typical tests were performed, and the results show that themaximum time delay is less than 50 ms. The developed data communication and management system isdemonstrated to be a high-performance system which can meet the requirements in our project.

C

ystem

. Introduction

Space laser communication technologies have gained a lotf national attention because of their advantages such as largeapacity, low power consumption, and high data rate. A laser com-unication system’s major specifications and performance need

o be tested and verified in the laboratory before the system isaunched. Presently, many countries have injected a substantialmount of human and financial capital to develop high-precisionnd high-performance ground test and verification devices (GTVD).xamples of these devices around the world include the Termi-al Test Optical Ground Support Equipment (TTOGSE) and Systemest Bed (STB) from the European Space Agency’s (ESA) Semi-onductor Laser Inter-satellite Link Experiment’s (SILEX) plan [1],apan’s Ground Optical Assistance for Laser Utilizing Communi-ations Equipment (GOAL) [2], the United States of America’sational Aeronautics and Space Administration’s (NASA) direct-etection free-space laser communications transceiver test-bed [3]nd Aerospace Corporation’s lasercom pointing, acquisition, andracking (PAT) test-bed [4], China’s Shanghai Institute of Opticsnd Fine Mechanics’ tracking and pointing performance measure-ent device, based on a rotating optical wedge [5], China’s Pekingniversity’s tracking and pointing accuracy measurement device

6], and China’s Harbin University of Technology’s link simula-ion platform [7]. Unfortunately, the GTVDs listed above can onlyest a single terminal machine, but the new GTVD that we are

∗ Corresponding author. Tel.: +86 10 62762772; fax: +86 10 62753208.E-mail addresses: digitaltech@pku.edu.cn (J. Wang), lifucaii@163.com (F. Li).

030-4026/$ – see front matter. Crown Copyright © 2013 Published by Elsevier GmbH. Attp://dx.doi.org/10.1016/j.ijleo.2013.09.071

rown Copyright © 2013 Published by Elsevier GmbH. All rights reserved.

currently co-developing is able to test two terminals simulta-neously, which is more similar to the actual situation when thespace laser communication systems are in orbit.

For a set of GTVD to qualify for space laser communication, itmust satisfy several criteria. First, it needs to be able to simulate,within limited space on the ground, various space environmentsand situations that would occur when the terminal system is inorbit such as the vibration of satellite platform, the backgroundlight, inter-satellite relative motion, and optical far-field receiving.Second, based on the simulated devices, it needs to measure impor-tant parameters such as the acquisition probability, the pointingaccuracy, and the point-ahead precision, while its measurementmust have a higher accuracy rate than the terminals measured. Adata communication and management system (DCMS) is necessarybecause, when the testing process is completed automatically, thevarious space environments and status simulation devices or mod-ules must cooperate with each other to simulate the work processesand states when the terminal system is in orbit. The DCMS alsoneeds to accomplish tasks such as collection of measurement data,distribution of control commands, control of measurement process,storage of data, and display of results or measurement status. How-ever, there are certain challenges to designing an optimal DCMS.First, the DCMS needs to be able to do both communicate or managea number of simulation position lower computers (PLC) and auto-matically control or manage hundreds of parameters, statuses, andcommands in the new GTVD. Additionally, millisecond-grade com-

munication delay for some of the data and commands is required.Another challenge that we face when designing the DCMS is theexistence of several types of communication interfaces and com-munication rates, which makes using a single type of interface

ll rights reserved.

1938 J. Wang et al. / Optik 125 (2014) 1937– 1941

nmtiagatf

acta

2

maiiePucwTc

idftuaimttrtDo

t

munication card installed, and they should be linked into the CANdata bus network via shielded twisted pair cables to communicate.Here, we analyze the CAN bus communication delay.

Fig. 1. Structure schematic diagram of the DCMS.

early impossible. Moreover, according to the structural require-ents of the GTVD, the communication distance is relatively far,

ypically greater than 40 m, and thus, the DCMS should have anti-nterference capabilities. So we can see that it is hard work to design

DCMS that manages hundreds of parameters, has millisecond-rade time delay and anti-interference performance, and works in

multi-tasking way using multiple buses under a considerable dis-ance. We have reviewed the existing literature but have not yetound articles about the design of such a DCMS.

In this paper, we outline our design of an original DCMS to man-ge the set of GTVD that we are co-developing. We analyze itsompositions and give the detail design procedures. More impor-antly, the field tests are done and the results show the system has

good performance.

. The composition and implementation

The DCMS that we designed, shown in Fig. 1, consists of theaster control computer (MCC), the hardware interface circuit,

nd the software. The MCC realizes the functions of communicat-ng with other subsystems, gathering, distributing, and handling ofnformation or other functions. The hardware and software portionnhances the exchange of information between the MCC and otherLCs by optimizing the appropriate form of bus and designing thenderlying drivers and communication program. The software partontrols the entire measurement process, displays the real-timeorking status, and stores measurement data into the database.

hese three together make up the core of the DCMS. The detailomposition and its main messages are shown in Fig. 2.

Fig. 2 also indicates its working process, as you can see, fromnside of the block diagram to outside. First, the MCC and the PLCso the hardware self-test, and then the users choose a test moderom the test types, which include acquisition performance test,racking performance test, acquisition and tracking joint test, andser-defined test. Second, the DCMS sets the parameters of the PLCsccording to the test mode selected. Third, the MCC sends pre-worknstruction to all the PLCs and confirms they can communicate nor-

ally. Fourth, the DCMS does the test and saves the test data intohe database. The complete working process, such as the test mode,he set parameters, the working status of the PLCs, the test data andesults, is displayed on the screen. In addition, the schedule of theest results can be shown on screen and the results can be printed.

uring the test process, if a PLC has a fault, the MCC will inform thether PLCs to terminate the test immediately.

During ground test of dynamic far-field simulation, the posi-ion precision of the one-dimensional turntable impacts on the

Fig. 2. The function diagram of the DCMS.

measurement significantly. It is acceptable if the angular position’sreal-time information error, caused by transmission delay, is lessthan 10% of the beacon width. However, if it is any greater than this,it will directly influence the measurement accuracy of the acqui-sition time and acquisition probability. Combined with real-worldconditions and taking other factors into account, we needed thecommunication time delay between the MCC and one-dimensionalturntable to be less than 50 ms.

2.1. Hardware design and implementation

The hardware platform of the DCMS includes the MCC, and allthe communication interfaces between the MCC and every PLC orterminal. To analyze the functional requirements of the DCMS andsome of the existing interfaces, we used an RS (RecommendedStandard)-232 interface and a parallel port to connect the high-precision one-dimensional turntable to the MCC, a 1553B bus toconnect the tested communication terminals to the MCC, and a CAN(Controller Area Network) bus to connect the rest of the PLCs to theMCC.

2.1.1. Hardware communication based on the CAN busThe PLCs that use the CAN bus to communicate are the wide-

angle beam scanner PLC, satellite platform vibration simulationPLC, point-ahead angle simulation PLC, acquisition monitor PLC,tracking monitor PLC, and background-light simulation PLC. TheMCC and PLCs listed above need to have a PCI bus-based CAN com-

Fig. 3. Schematic of an extended frame’s longest single-frame.

k 125 (2014) 1937– 1941 1939

se

ammM

i

2

4daFutc

2

1twtc

csdttic

wcmtc

2p

dMbp

tuwtdm

dmaLipd

that the DCMS needs to implement many functions, we design themain software composed of many modules, which contain a mea-surement parameters’ initialization module, eleven measurementprocess modules, ten display modules, a data processing module, a

J. Wang et al. / Opti

We adopted the CAN2.0B bus protocol for this project. Fig. 3hows the breakdown of the 29-bit ID’s largest single-frame in thextended frame.

From Fig. 3, we can see that after taking bit-stuffing into account,nd excluding the 8 bytes that contain data segments, the maxi-um frame length is 86 bits. By definition of the parameters in eachodule, we know that the total number of message types that theCC receives from the CAN bus is 28.When the CAN bus’ data rate is 500 kbps, its maximum theoret-

cal network delay is

8(

64 + 86500k

)= 8.40 ms

The maximum theoretical network delay of the CAN bus is.20 ms under a 1 Mbps data rate. In addition, the implementationelay of a single CAN message cannot exceed 10 ms. The analysesbove shows that the CAN network will not cause much of a delay.urthermore, all the CAN nodes are equipped with effective meas-res for error detection, calibration, and self-checking includingransmission self-checking, bit-stuffing, CRC, and message formathecking, to ensure a low error rate.

.1.2. Hardware communication based on the 1553B busThe MCC communicates with the satellite terminals using the

553B bus. We chose the 1553B bus because it is a general dataransfer bus within the satellite. The MCC needs to be installedith a 1553B communication card based on PCI, and linked into

he 1553B data bus network through shielded coaxial cables toommunicate with the terminals.

The contents of communication with the terminals include someontrol commands, such as commands to start work and stop work,o it does not parse through too much data. Since the maximumata rate of the 1553B bus is 1 Mbps, even though the MCC and thewo communication terminals transmit messages simultaneously,he time from which the messages are sent until they are processeds very short. Therefore, the time delay will not influence the dataommunication.

In the GTVD, the distance between the terminal and the MCCas approximately 15 m, so we adopted multiple couplers and

urved wiring to ensure the accuracy and immediacy of data com-unication. We also utilized redundant backup methods, namely,

he wired two channel network, to ensure the reliability of dataommunication.

.1.3. Hardware communication based on the RS-232 andarallel port

The MCC communicates with the high-precision one-imensional turntable using RS-232 and parallel ports. TheCC needs a serial port and a parallel port communication card

ased on the PCI bus and communicates through serial lines andarallel lines.

The contents of communication with the turntable are mainlyhe photoelectric encoder data and some status commands. Wesed the parallel port card to read the photoelectric encoder data,hich has one thousand pieces of data per second. In fact, the real-

ime angular position’s transmission rate is 2.344 kbps while theata transfer bandwidth of PCI bus is up to 32 Mbps, so it easilyeets the requirements of data acquisition speed.The communication distance extends to 20 m, but if we use a

irect connection approach, the data can only be transmitted a feweters away due to attenuation. To solve this problem, we designed

repeater, which includes parallel/serial conversion circuits, a

ow Voltage Differential Signaling (LVDS) driver, and an equal-zer, shown in Fig. 4. The parallel-to-serial converter converts thearallel data from the one-dimensional turntable into LVDS serialata, which is to be transferred through twisted-pair cable after

Fig. 4. The repeat circuit diagram.

being enhanced by LVDS driver. Then the LVDS data is convertedinto parallel data by serial-to-parallel converter and transferred tothe MCC. We chose the XC2S50E chip XILINX Corp developed forthe FPGA controls chip, which is mainly responsible for the controlof LVDS converters [8]. The parallel-to-serial converter adopts theDS92LV1023 chip while the serial-to-parallel converter adopts theDS92LV1224 chip. The LVDS driver is a CLC001 chip, which adoptsdifferential input and output. It drives the twisted-pair cable by AC-coupling and then the signals are transferred to the equalizer, alsoby AC-coupling. The adaptive equalizer adopts CLC014 chip, andit equalizes the transmission signals. Experimental results demon-strated that the repeater circuit did not appear to be a source ofbit error or bit loss in the data transmission. By using this technol-ogy, the transmission distance could be extended to nearly 100 m,which satisfied the designated communication requirement.

The remaining types of communication messages were trans-ferred by a 20-m RS-232 serial cable. As there is not much data,its 115,200 bps baud rate fully meets the bandwidth and delayrequirements.

2.2. Protocols, software design and implementation

2.2.1. The design of the protocols2.2.1.1. Interface protocol of the CAN bus. We used the CAN 2.0Bextended frame protocol. Fig. 5 shows its 29-bit identifier, includingparameter ID, destination address (DA), source address (SA), andreserved bits.

We assigned appropriate addresses for the nodes of the MCCand the six PLCs in the CAN network and assigned a broadcastaddress to send centralized control commands such as commu-nication checks, start or stop work. Furthermore, we also definedthe transmission repetition rate of each message so that the corre-sponding messages are transferred again at regular intervals.

2.2.1.2. Interface protocol of the 1553B bus. Each data frame ofthe 1553B, displayed in Fig. 6, includes a command word, a dataword, and a status word. During the test process, the MCC (as BusController) periodically detects whether the terminal (as RemoteTerminal) has an abnormal status. If it does display an abnormalstatus, the MCC will fix them appropriately and ensure the stabilityof the entire measurement process.

2.2.2. Software design and implementationThe software system of the DCMS includes two categories, the

main software and the underlying software. Taking into account

Fig. 5. Distribution diagram of the 29-bit identifier of CAN bus.

1940 J. Wang et al. / Optik 125 (2014) 1937– 1941

dttub

ui

(

(

(

(

3

dm

3

ust

3

5smi

3lns

3

roi

real-time performance by simulating communication with differ-ent remote terminals. The DCMS provided precise communicationwhile performing associated debugging with actual communica-tion terminals.

Fig. 6. The structure of the 1553B frame.

atabase module, a driver module, and a print module. The task ofhe main software is focused on the management of the test process,he optimization of data processing, and the front interface. Thenderlying software mainly completes the communication tasketween the MCC and the PLCs.

The DCMS’s software is based on the Windows XP platform,sing Visual Studio 2008 Tools for programming. The software is

mplemented according to the following indicators:

1) Issue or receive various commands and parameters of differentPLCs, and real-time processing.

2) Determine, distinguish, and handle the alarm signal of everyPLC, to ensure the integrity and soundness of the DCMS.

3) The time delay is small, and processes the return data of differ-ent sizes with corresponding priority.

4) Appropriate flexibility, and easy to control the interface. Thatmeans you can test the performance of the whole GTVD as wellas that of a PLC separately.

. Field test results

After the completion of the DCMS’s hardware and applicationesign, we performed field testing of the DCMS to verify its perfor-ance.

.1. Field test of the CAN bus communication

We used CANoe, a bus development simulation tool, to sim-late communication and data transmission between differentubsystems and the MCC to verify the CAN bus network load, theransmission delay, and the integrity of our software.

.1.1. CAN bus network load testingWe fixed the CAN bus length at 40 m and the baud rate at

00 kbps. When CANoe simulated three periodic data messageources and periodically sent messages to the CAN bus, the dataessages and bus occupancy rate that CANoe monitored are shown

n Fig. 7.In Fig. 7, we can see that the average bus occupancy rate was

.70% with a peak value at 4.93%. The theoretical rate was calcu-ated to be 4.14%. Since the bus occupancy rate is low, the CAN busetwork’s bandwidth can sustain communication between the CANubsystems and the MCC when transferring data simultaneously.

.1.2. CAN bus transmission delay testing

We modified the DCMS’s main program so that it immediately

eturned a message of 8 bytes in length when the first byte’s contentf the CAN message received was 0x05. We used CANoe to mon-tor the bus and calculated the time difference between the two

Fig. 7. Screenshot of bus messages sent by PLCs CANoe simulated under 500 kbps.

messages, which included the software and hardware delay timethat the DCMS receives, processes, and distributes the two mes-sages.

The delay diagram displayed in Fig. 8 shows that the process’hardware and software delay �t includes the DCMS receivingmessage time tr and the sending message time ts, which means�t = ts + tr. The delay during which the DCMS receives data fromthe CAN bus is equivalent to the delay during which it sends datato the CAN bus, thus �t = ts + tr = 2ts = 2tr.

In the experiment, we collected 100 groups of test data ofintegrated transmission delay from the CAN-bus hardware andsoftware, and obtained the average delay �t = 0.334 ms. The totaldelay of the software and hardware when DCMS sends or receivesdata based on the CAN network is around 0.167 ms, which meansthe time delay of the CAN-bus is very low.

3.1.3. CAN bus frame conflict testingCAN 2.0B provides perfect support for the arbitration of data

conflicts, and its efficiency is also very high. The theoretical cal-culation and actual CANoe simulation both showed that the busoccupancy rate was less than 10% when the CAN network workednormally, but it is still possible for a conflict frame to occur. Fig. 9 is awaveform diagram of the frame conflict simulated under 500 kbps.

The diagram shows two frames close together where the frameinterval is 10 ms. It can be seen from the enlarged diagram thatthe content of the two frames’ and interframe’s ware frame tail ofimplicit electrical level. Thus, it can be determined that the con-tinuous transmission happened after the conflict between the twoframes occurred. We proved that the CAN bus network’s arbitrationmechanism is reasonable.

3.2. Field test of the 1553B bus communication

We used the TestSim, a test tool of 1553B bus, to test the1553B network and software part, and proved its accuracy and

Fig. 8. Schematic diagram of the CAN bus transmission delay testing.

J. Wang et al. / Optik 125

F(

3

aTrodd

3

tcatuj

(

(

(

(

(

(

(

t

[

[

[

[

[

[

ig. 9. Waveform diagram of frame conflict when the data were sent under 500 kbpsenlarged).

.3. Field test of the RS-232 and parallel communication

We also tested the one-dimensional turntable and achieved serial communication bit error rate of zero under 115,200 bps.he real-time angular position data that the DCMS databaseecorded was consistent with that sent by the high-precisionne-dimensional turntable. Additionally, the angular position dataisplayed by the interface and that on the high-precision one-imensional turntable interface were identical.

.4. Test of software function

We did associated testing with all the PLCs and communica-ion terminals to verify the application’s performance. The GTVDan test two communication terminals, which we defined as GEOnd LEO, and the test modes include acquisition performance test,racking performance test, acquisition and tracking joint test, andser-defined test. The test steps for the acquisition and tracking

oint test are as follows:

1) GEO is placed in position waiting for the demo, LEO is placed inthe reference light source and the optical axis is aligned.

2) The MCC starts up and does communication test with each PLC,and we set the test mode and parameters.

3) The DCMS allows the background-light PLC and the satelliteplatform vibration PLC to turn on, and allows the 1D turntableand wide-angle beam scanner PLC to simulate the orbit motionaccording to a certain angular velocity.

4) The DCMS informs GEO to start scanning after a certain timedelay.

5) GEO scans the uncertain region using the beacon light and whenLEO receives the beacon, it seeds an un-modulated signal lightto GEO as feedback in the same way after a delay of 0.3 .

6) When GEO receives the feedback signal light, it sends an un-modulated signal light to LEO after internal adjustment. WhenLEO receives the un-modulated signal light, it returns a signallight to GEO.

7) GEO begins to track and the DCMS records the tracking data,

tests the communication performance using bit error tester.

The other test modes’ processes are similar to this. During theest, the DCMS collected data from the subsystems and stored

[

[

(2014) 1937– 1941 1941

them into the database after preliminary processing, while simul-taneously displaying it on the interface in real-time. We saw themeasurement parameters changing continuously in the main win-dow. After analyzing the data stored in the database, we found thatall the required parameters were correctly stored in the database inreal-time. Furthermore, the software can be easily extended, whichmeans we can add new measurement processes based on what isactually required.

In brief, according to the field test results, the main technicalspecifications that the DCMS achieves are as follows:

(1) Communication distance. CAN −40 m, 1553B −15 m, RS-232and Parallel −20 m.

(2) Communication rate. CAN −1 Mbps/500 kbps, 1553B −1 Mbps,RS-232 −115,200 bps, Parallel −1 Mbps.

(3) Data transmission delay. Orbit simulator’s data transfer delayis less than 50 ms.

(4) The application is able to do the initialization and the corre-sponding management over PLCs according to requirement,give the state and environmental parameters that the PLCsdemand, and has data storage function.

(5) The application is efficient, precise, and stable. The interface isuser-friendly and easy to operate.

4. Conclusions

In this paper, we presented a practical design for the data com-munication and management system which manage and controlthe test process of the ground test and verification devices. The fieldtests show that the data communication and management systemreached a certain performance in respect of certain communica-tion distance, fast transmission, low time delay and high efficiency.In addition, our data communication and management system caneasily be used in other ground test and verification devices afterappropriate modifications according to the actual needs.

Acknowledgements

This work was supported by Ministry of Industry and Informa-tion Technology and National Defence Technology Basic ResearchProject during 12th Five-year Plan Period (Grant No. J312012A001).The authors would like to thank our collaborators who wereinvolved in the development of the new ground test and verificationdevices.

References

1] G. Planche, B. Laurent, J.C. Guillen, E. Desplats, SILEX final ground testing andin-flight performances assessment, Proc. SPIE 3615 (1999) 64–77.

2] K. Nakagawa, A. Yamamoto, Performance test result of LUCE (Laser Utiliz-ing Communication Equipment) engineering model, Proc. SPIE 3932 (2000)68–76.

3] M.A. Krainak, J.R. Chen, P.W. Dabney, et al., Direct-detection free-space lasertransceiver test-bed, Proc. SPIE 6877 (2008) 687703.

4] J.N. Tanzillo, C.B. Dunbar, Shinhak Lee, Development of a lasercom test-bed forthe pointing, acquisition, and tracking subsystem of satellite-to-satellite lasercommunications link, Proc. SPIE 6877 (2008) 687704.

5] L.R. Liu, L.J. Wang, J.J. Sun, et al., An integrated test-bed for PAT testing andverification of inter-satellite lasercom terminals, Proc. SPIE 6709 (2007) 670904.

6] J.M. Wang, L.L. Wang, Q. Xu, Y. Qin, Analysis of the far field distribution mea-surement of the terminals of free space laser communication and the measuring

system design, J. Optoelectr. Laser 19 (11) (2008) 1467–1473 (in Chinese).

7] M. Lian, H.Y. Fu, Control system of link simulator for space optical communica-tion, Infrared Laser Eng. 38 (1) (2009) 101–1059 (in Chinese).

8] X.Y. Dai, L.H. Wang, S.K. Li, S.H. Zhang, Design of multiple interface of long linetransmission based on LVDS, Commun. Technol. 42 (11) (2009) 4–6 (in Chinese).