Home

Paper - STS

1. ATLAS test Number of Number of unknown Number of unknown program name code lines code lines absolute code lines relative EAU 3849 0 0 HYDIM 1774 197 11 ECSMC 1978 241 12 PDCU 1776 205 12 OEU 983 158 16 SZUM 2233 355 16 SDM 1039 194 19 WEU 4753 910 19 CSC 2292 464 20 ASG 1979 445 23 LMC 3482 988 28 Table 5 1 Unknown Code lines in different transformed Programs First of all the testing reveals that the test system is robust enough to translate every ATLAS ARINC 626 3 Spec code line without the occurrence of parsing errors In addition it appears that the statement definitions of the ATLAS grammar were precise enough to avoid pushing the limits of hardware while parsing An ambiguous grammar can easily exceed the capacity of computer memory while parsing even if 49 5 Evaluation STS the program is small The results show that 70 to 90 percent of the ATLAS statements were successfully transformed to an equivalent Teststand step This could save a lot of time when translating test programs even if they could not be converted to 100 percent Fur thermore this result supports the assumption that avionic test programs are similar in most parts or at least use the same ATLAS statements There are some situations to consider were Teststand steps are transformed cor rectly but do not work immediately e Unknown expressions do not lead to unknown code lines
2. Sequence name Parameters ATLAS code Creates a Sequence Call Step that invokes another sequence The Seguence name variable states the Name of the invoked sequence In the Parameters a comma separated list contains the transfer parameters step SignalCall Statement number Action Sequence name Parameters ATLAS code Creates a Sequence Call step that activates one of the Sequences which contain the hardware triggering Action represents the kind of call APPLY etc The Sequence name variable indicates the Name of the Hardware Sequence to be invoked In the Parameters a comma separated list contains the transfer parameters step EventCall Statement number Action Event name ATLAS code Creates a Sequence Call step that calls a sequence that is connected with an event At launch a global variable is retrieved which contains all events and their parameters There is no need to transfer parameters at this point The name of the event is deposited in Event name step ExchangeCall Statement number Action Exchange name Parameters ATLAS code Creates Seguence Call step that calls one of the sequences which are connected with a bus protocol At launch a global variable is retrieved which contains some of the parameters The name of the exchange protocol is filed in Exchange name Further parameters are exchanged via Parameters 44 4 The Translator STS Sequence
3. This category contains all macros that are necessary to create a sequence and to control in which sequences variables and steps shall be saved sequence BuildSequence Sequence name Sequence type Creates a new sequence with the name Sequence Name The Sequence type variable solely creates a sequence description for aesthetic purposes that has no effect on the procedure sequence BuildChapter Chapter name Creates a new chapter A chapter is a specific sequence that is called from the start sequence automatically MainSequence A chapter holds a complete testchapter Chapter are independent from one another and create entry points of the test program Before every test run one can decide which test chapter should be launched sequence SetSequence Sequence name Sets the global variable FileGlobals ActualSequence which contains the reference of the current sequence to the sequence with the name Sequence Name All subsequent steps and variables are therefore automatically written into this sequence sequence RestSequence Sets the global variable FileGlobals ActualSequence back to the MainSeguence Variable This category contains all makros for the creation of variables variable Names Type Location Initials Declares and initializes variables Names is a comma seperated list with variable names and Initials is a comma seperated list with their initial values Types states t
4. where Test if start and end procedure names are equal Name Namel construct Inputparameter list A_input_ parameter _ getInput Parameter construct Outputparameter list A output_ parameter _ getOutput Parameter construct Input repeat T_ variables _ convertParameterInput each Inputparameter construct Output repeat T_ variables convertParameterOutput each Outputparameter by sequence BuildSequence Name Procedure 30 18 19 20 21 22 23 4 The Translator STS sequence SetSequence Name variable Variables Container Locals Input Output SubScope proceduralTransformations sequence ResetSequence end rule The procedure transformation rule is shown in Listing 4 6 In line 7 the name con dition is checked The input and outputparameters are converted in lines 13 and 15 and the resulting macro commands are concatenated with the TXL built in function in line 20 Statements and local variables of the procedure are stored in the Sub Scope variable To transform the content the procedure Transformations function is called The macro commands SetSequence and ResetSequence in lines 18 and 22 make sure the variables and statements are put into the right sequence by the assembler Variable Types Table 4 2 illustrates the different variable types available in ATLAS what they are transforme
5. Statements Signal statements primarily control the hardware components The ARINC speci fication 626 3 combines them in the chapter Procedural statements signal 5 189 38 4 The Translator STS Evaluation Value of Conditions Teststand Field Format Variable v Established equivalent UL y LL z v gt y Hi amp NOGO GELE yz y gt v gt z GO z gt v LO amp NOGO GT x v gt x GO GT x v lt x LO amp NOGO LT x v lt x GO LT x v gt x LO amp NOGO EQx v x GO EQ x v lt gt x LO amp NOGO NE x v lt gt x GO NE x v x LO amp NOGO GE x V gt 2 GO GE x v lt x LO amp NOGO LE x vIr GO LE x v gt x LO amp NOGO Table 4 4 Evaluation Field Relationships from Table 14 1 5 274 Therefore hardware control is not in the scope of this work the control actions as well as the values and limits are passed to the according hardware sequence So most of these statements can be transformed with one rule Statements that can be transformed by the rule transformSignal in listing 4 15 APPLY REMOVE CHANGE SETUP CONNECT DISCONNECT ARM FETCH RESET VERIFY 39 1 17 4 The Translator STS e READ Listing 4 15 Signal Statement Transformation Rule rule transformSignal replace procedural_statement F A_fstatno Verb A_ signal_verb Mes A_measured_char Noun A_noun_ field Body list A require body _ opt A_field_separator Cnx A_conn_sig
6. They don t contain any procedural statements with the exception of procedures and functions Extend statements provide means to add supplementary definitions for signal and for bus parameters protocol parameters bus modes and test equipment roles to the ATLAS language Require statements describe and label the requirements on different hardware re sources These test resources are termed virtual resources and represent a link between the test software and the real resources The checking and assignment of virtual resources to real resources is a complex implementation problem which is outside the scope of this work Declare statements establish label and identify data types constants and variables Establish statements specify a bus protocol for later use with do exchange state ments Define statements establish and label parts of the test software which are not exe cuted until the label is mentioned direct or indirect in a subsequent procedural state ment The procedure and function structure contain ATLAS procedural statements that are often used in the program flow Identify statements label and describe events that allow the establishment and im plementation of signal and test action timing relationships 14 3 Test Language Transformation STS HL Figure 3 3 ATLAS Preamble Structure il 15 3 Test Language Transformation STS The main procedural structure is where the execu
7. _ File Table 4 2 ATLAS and Teststand Variable Type Comparison 4 1 2 Flow control Flow control statements provide the capability to control the order of statement execution The ARINC specification 626 3 combines them in the chapter Procedu ral statements control 5 Because short circuit semantics are not mentioned in the 32 oF WN m O0 JO 10 11 12 13 14 15 16 18 19 4 The Translator STS specification it is assumed that they are not implemented whereas TestStand does implement short circuit evaluation This difference could be compensated by manip ulating the underlying C code of the relevant flow control steps but this is outside the scope of this work Given that the example source code doesn t use conditions that would be violated by short circuit evaluation this difference is irrelevant for the evaluation Nevertheless it needs to be considered for other source code transforma tions in the future If then else else if Structures These structures control the execution of statements provided that certain condition expressions evaluate to true or false The functional flow of these structures is shown in the ARINC specification 626 3 5 on page 151 The semantics are very similar to each other so the transformation to Teststand is very straight forward Listing 4 7 illustrates the different transformation rules needed The statements IF ELSE IF ELSE LEAVE and END have
8. a non terminal at the head of the production replaces a specific substring matching the body One form of bottom up parsing is shift reduced parsing A stack holds the grammar symbols and an input buffer holds the rest of the string The parser than does a left to right scan where it shifts zero or more input symbols onto the stack until it is ready to reduce a string p of grammar symbols on top of the stack 6 is then reduced to the head of the appropriate production This cycle is repeated until the stack con tains the start symbol and the input is empty or until the parser has detected an error This leads to four possible actions a shift reduce parser can make 1 Shift The next input symbol is shifted onto the top of the stack 2 Reduce Reduce the right end of the string that must be at the top of the stack Decide with what non terminal to replace the string that is located on the left end of the string within the stack 3 Accept Parsing has been completed successfully 4 Error A syntax error has been discovered Call an error recovery routine 2 Transforming Languages STS The largest class of grammars for which shift reduce parsers can be built are called LR grammars 2 2 Source Transformation tools 2 2 1 The Turing eXtender Language The original purpose of the Turin eXtender Language TXL in the early 1980 s was to stretch the Turing programming language to include new language features The developers fo
9. beginning with a digit and continuing with any number of digits an optional decimal point followed by at least one more digit and an optional exponent beginning with the letter E or e and followed by an optional sign and at least one digit 7 4 Listing 2 1 Simple Example Grammar from TXL Cookbook 6 define program expression end define define expression term No oon 10 12 13 14 15 16 17 18 19 20 aOowobkwWN EH 2 Transforming Languages STS expression term expression term end define define term primary term primary term primary end define define primary number expression end define Rules and functions After parsing the source language into a parse tree according to the explained gram mar the rules and functions that are responsible for transforming the input parse tree into the output parse tree are applied The difference between a rule and a function is that a rule searches the scope of the tree it is applied to for matches to its pattern and replaces every match where a function just replaces the first match Listing 2 2 Simple Example Rule from TXL Cookbook 6 rule addOnePlusOne name replace expression target type to search for 1 1 pattern to match by 2 replacement to make end rule The Listing 2 2 illustrates a simple example rule Every rule function consists of a name line 1 a type line 2
10. building Therefore a grammar that describes the TestStand macros is necessary Because of the lack of formal seman tic definitions of ATLAS and TestStand there is no formal method of proofing the semantics of the transformed source code correct so we need to look at each trans formation rule individually Unparse and Assemble In the unparse phase the parse tree is assembled to an intermediate code that consist of simple commands for construction of the final sequence files We call this code TestStand macros In the assemble phase these macros are then read by a program the TestStand macro assembler that is capable of constructing the TestStand se quence file 1 3 Goals The goal of the thesis is to develop a robust transformation system that is capable of migrating ATLAS source code into running TestStand sequences The transforma tions as correct as possible by observing each transformation rule individually and by comparing the output a transformed program produces with the output of the source 1 Introduction STS program This leads to the following contributions e Semantics Identify relevant means to describe and compare semantics Develop a robust grammar to specify Original Equipment Manufacturer OEM Software syntax Introduce rules to transform one high level language into the other e Tool Construct an assembler program to produce the binary sequence file of the new system Des
11. for the maintenance In this market segment Maintenance Repair and Overhaul MRO companies like Lufthansa Technik AG LHT provide a complete maintenance solution for all aircraft components for airlines To repair and certify a flight component a test according to the manufacturer speci fication is mandatory Historically the test specification is often provided as Abbrevi ated Test Language for All Systems ATLAS The development of the test language ATLAS started in 1967 The purpose of the original version ARINC Specification 416 was an application and documentation language for manual and automatic test ing of airline avionics It was designed to describe both the test procedure and the needed hardware resources in a way that engineers could simply understand the in structions with no room for misunderstanding Nowadays it became more and more an ineffective way to host this old language to modern measurement instruments Due to the slow execution speed and the fact that ATLAS does not support digital bus systems changes the way testing of digital flight computers is implemented But a manually programmed test program is very cost intensive 1 2 General Approach To make it possible to use the ATLAS test specifications we need to develop a method to convert the ATLAS source code into TestStand an up to date programming lan guage The general approach in this work is source to source transformation The requirements on such a tran
12. parameters provide the possibility to transfer values from and to the procedure or function during calls Procedures can be called by a perform statement 29 wm O OND oe 10 12 13 14 15 16 17 4 The Translator STS and functions are used in an expressions similar to variables The equivalent repre sentation in Teststand is a sequence with the cutback that sequences can t be called in a expression However the solution to this restriction was outside of the scope of this work therefore the case study doesn t contain functions This section focusses on the definition of procedures DEFINE Procedurename PROCEDURE nputparameters RESULT Outputparameters Local variable definitions ATLAS procedural statements END Procedurename Figure 4 2 ATLAS Procedures Figure 4 2 illustrates the schematic representation of ATLAS procedures Inputpa rameters Outputparamets and local variable definitions are optional The DEFINE and END statements act as delimiter at the start and end of the procedure where the Procedurename acts as a unique identifier To compare the names the best way is to transform the hole structure altogether Listing 4 6 Procedure Transformation Rule rule transformProcedure replace preamble_statement F A_fstatno DEFINE Name charlit PROCEDURE Parameter A parameter_definition SubScope repeat procedural_statement F1 A_fstatno END Namel charlit
13. the transformation of unknown code lines by hand or the identification of semantic failures e A big point that has led to the transformation of ATLAS test case descriptions into TestStand sequences at all is that some structures such as digital bus systems in ATLAS can only be realized with complicated and slow workarounds A process that recognizes these cumbersome workarounds and improves them according to the possibilities that TestStand offers could optimize the clarity and the performance of the test program significantly e The mapping of the virtual resources of the test case descriptions to real re sources of the automatic test environment and the control of these hardware components in TestStand is still a manual task A process that automates this approach could save a lot of time and reduce the likelihood of errors 57 Listings STS Listings 2 1 Simple Example Grammar from TXL Cookbook 6 8 2 2 Simple Example Rule from TXL Cookbook 6 9 3 1 Unknown Statement Definition o a 22 4 1 Basic ATLAS grammar structure 2 2 Co on a 26 4 2 ATLAS Require Source Example Statement 27 4 3 ATLAS Apply Example Statement 28 4 4 Transform Require Rule o e e 28 4 5 Convert Require Function o 28 4 6 Procedure Transformation Rule 2 0 o 30 4 7 Tf then else else if Tranformation Rules 4 33
14. the timing This error can be explained as follows Figure 5 3 illustrates three steps from the example program In the first step a 5V DC Source is applied to a HI pin J14 22 After a 2 5 second waiting period the DC Source is disconnected The idea is to have 5V on the pin J1A 22 for exactly 2 5 seconds Unfortunately the activation of the relays and the triggering of the DC source leads to a delay therefore a 5V slope of 3 seconds can be measured This can have an influence on the UUT and explain the false measures APPLY DC SIGNAL USING gt SUPPLY VOLTAGE 5 0 V ERRLMT 0 25 V CNX HI J1A A Yu N A Call 5 VDC SUPPLY in lt Cument File gt nn WAIT FOR TIME 2 5 SEC a e AE Tena a Vo u REMOVE DC SIGNAL USING 5 VDC SUPPLY VOLTAGE 5 0 V ERRLMT 0 25 V CNX HI J1A 22 Li REMOVE Call 5 VDC SUPPLY in lt Current File gt Figure 5 3 Hardware Timing Problem 54 6 Conclusion STS 6 Conclusion This chapter concludes the thesis with a summary of the results and an outlook to future work The goal was a semantic preservative transform from ATLAS test case descriptions to TestStand sequences This goal was achieved in this work and was evaluated by means of a case study The result is a working prove of concept The method greatly simplifies the migration process of two test languages At first we developed a grammar to parse the ATLAS test case descriptions into a parse tree The grammar is designed in a way
15. to perform tests on a Unit Under Test UUT using automation for measurements and evaluation of test results Tests can be performed by a single computer controlled digital multimeter up to a complex system utilising multiple test instruments as well as AC and DC sources A desktop computer runs the test software and controls the test instruments via different connections like PCI PCle Ethernet PXI PXIe USB GPIB and several more Fast switching of instruments are realized by relays A Test Unit Adapter TUA is then used to connect the sensors and sources necessary for the test with the UUT This makes it possible to test multiple different UUTs using the same test system but different test software and adapters Automatic test environments are widely used by electronics manufacturers for test ing of components after fabrication or by avionics and automotive companies for maintenance and repair Especially units that require regular testing of all parame ters like components that are critically important for human live offer and area of application for automatic testing ATLAS and TestStand are both programming languages for development of test software for automatic test environments The difference is that the ATLAS test software includes a hardware description of the TUA components This information need to be extracted before transformation because hardware descriptions can not be mapped to the TestStand software 3 2 Requirements o
16. 2 2222 nn a 11 3 Test Language Transformation 13 3 1 Test Software for Automatic Testing 2 2 22 2 13 3 1 1 ATLAS The Language for all Systems 2 2 2 222 20 13 3 1 2 TestStand The Industry Standard Test Management Software 18 3 1 3 Automatic test environments 2 2 2 2 2 nn a 21 3 2 Requirements on the Translator 2 2 2 2 2 nme 21 3 2 1 Parsing ATLAS Syntax 2 2 Eon nn 22 3 2 2 Preserving Semantics in Avionic Environments 23 4 The Translator 25 4 1 Transformations sooo 26 4 1 1 Preamble ee 27 4 1 2 Flow control Comm 32 4 1 3 Data Processing e 37 4 1 4 Hardware Control Statements 2 2 22 nn 38 4 1 5 Expressions 0 ee ee ee 40 4 2 Teststand Assembler 2 2222 Con o nn 41 4 2 1 Concept sa wa bese lh ats aa ne ns 42 4 2 2 Construction Examples 2 22 CE nn 46 5 Evaluation 49 5 1 Applicability 0 2 200 002 0200 0 2020004 49 5 2 Case Study 50 5 2 1 Limits esse ee eee eee eae Ee A e a a aia 51 5 2 2 Rimtestss a u oak eos wk a a ee 52 iii Contents STS 6 Conclusion 55 6 1 Future Work s i sorodu arang sors be Be a a 57 Acronyms STS Acronyms AEEC Airlines Electronic Engeneering Committe API Application Programming Interface ARINC Aeronautical Radio Inc ATE Automatic Test Enviroments ATLAS Abbreviated Test Language for All Systems CMM Component Maintenance Manual GUI Graphical User Interface IEEE Institute o
17. 2 3 14 14 14 2 4 9 9 9 2 5 101 101 101 2 6 70 70 70 2 1 91 91 91 2 8 ol 51 50 2 9 37 36 36 3 1 25 25 25 3 2 148 148 148 3 3 14 14 14 3 4 9 9 9 3 5 101 101 101 3 6 70 70 70 3 7 91 91 91 3 8 ol 51 50 3 9 37 36 36 Table 5 2 Checking Limits and Test Step Order be associated with a defective transformation The comparison of the limits leads to the conclusion that the ATLAS source pro gram that generated the reference report was not identical with the used exemplary program We can assume that errors from the ATLAS program code have been fixed in the program for the reference report 5 2 2 Runtests To review the semantics the test program is used on a test rig to examine an UUT UThe same UUT was used to compare the generated report with an existing ATLAS report The measured values in the TestStand report have to coincide with the AT LAS report An error occurred due to the transformation but was fixed immediately after wards The pre defined function COPY A B C copies a substring of string A from character index B with length C In TestStand the equivalent function is Mid A B C The only difference led to the failure Character index B starts in ATLAS with 1 and 52 5 Evaluation STS 23 294010 FileGlobals MAX_TIME 6 era FileGlobals GO TRUE Bse iia FileGlobals GO FALSE End Figure 5 2 Incorrect Variable Monitoring in TestStand with 0 Table 5 3 shows the last res
18. 4 11 Finish Transformation Rules rule transform_ Finish replace procedural_statement F A_fstatno FINISH by step Finish F Finish F FINISH end rule Wait This statement suspends the program execution until a condition is satisfied It is possible to wait for a certain time a specific timer to reach a specified time quantity a particular event to occur or a human manual intervention In the scope of this work just the first condition is transformed therefore the other options aren t used very often Listing 4 12 illustrates the transformation rule The equivalent Teststand step to a wait for time statement is a wait step Because the ATLAS statement considers the time dimension and the Teststand step always uses milliseconds the convertTimeDim function in line 7 converts the time dimensions accordingly Listing 4 12 Wait Transformation Rules rule transform Wait replace procedural_statement F A_fstatno WAIT FOR TIME Time A_time quantity construct T_time number 0 by 36 4 The Translator STS step NI_Wait F Wait T_time converTimeDim Time F WAIT FOR TIME Time end rule 4 1 3 Data Processing Data processing statements provide the capability to save test values for further use in the test procedure perform calculations on these value and compare test values with specified limits Calculate The ca
19. 4 8 While Tranformation Rules 2 22208 34 4 9 For Tranformation Rules 2 2 m Emm nn 35 4 10 Perform tranformation Rules 2 2 on nn nn 35 4 11 Finish Transformation Rules 2 2 CE nn nn 36 4 12 Wait Transformation Rules 2 2 22 o nn 36 4 13 Transform Calculate Rule 2 2 2 Co Eon nn 37 4 14 Transform Compare Rule 2 2 om nn nn 38 4 15 Signal Statement Transformation Rule 40 4 16 Using TestStand API to build a new Step 47 4 17 Building a For Step using the TestStand API 48 58 Bibliography STS Bibliography 1 Alfred V Aho Monica S Lam Ravi Sethi and Jeffrey D Ullman Compilers Principles Techniques and Tools 2Nd Edition Addison Wesley Boston MA USA 2007 David T Barnard Automatic generation of syntax repairing and paragraphing parsers Master s thesis University of Toronto April 1975 Peter Borovansky Claude Kirchner Helene Kirchner Pierre etienne Moreau and Christophe Ringeissen An overview of elan Elsevier Science 1998 Mark Brand Jan Heering Paul Klint and Pieter A Olivier Compiling language definitions The asf sdf compiler Technical report CWI Centre for Mathe matics and Computer Science Amsterdam The Netherlands The Netherlands 2000 AIRLINES ELECTRONIC ENGINEERING COMMITTEE STANDARD AT LAS LANGUAGE FOR MODULAR TEST AERONAUTICAL RADIO INC 2551 RIVA ROAD ANNAPOLIS MARYL
20. A Numeric Limit Test Important information are the variable name 37 w CO OND oe 10 4 The Translator STS the dimension of the value it represents the evaluation format and the limits For the report we also need the test step number TSN and a test description Listing 4 14 shows the transformation rule in TXL Listing 4 14 Transform Compare Rule rule transformCompare replace procedural_statement F A_fstatno COMPARE Var charlit Comp repeat A_comparison_value construct Dim A_dim NODIM construct Body repeat T_compare_ body _ getCompareValues each Comp by step VISA_ NumericTest F Compare Var Dim getAtlasDimension Comp Body F COMPARE Var Comp end rule The function getAtlasDimension in line 9 does aestetic transformations to the ap pearance of the dimension description in the report Table 4 3 shows the conversions we needed for the case study The function getCompareValues in line 7 transforms the evaluation field Comp repeat A_ comparison value that is expressed in line 3 ATLAS Teststand dimension dimension USEC us MSEC ms SEC S Table 4 3 Dimension Conversions To get the possible evaluation formats for the evaluation field we need to take a look at table 4 4 Each row lists a field format and the result different variable values will establish 4 1 4 Hardware Control
21. AND 21401 arinc specification 626 3 edition January 1995 James R Cordy Excerpts from the txl cookbook In Proceedings of the 3rd International Summer School Conference on Generative and Transformational Techniques in Software Engineering III pages 27 91 2011 James R Cordy The TXL Programming Language Version 10 6 Queen s University at Kingston Kingston Ontarion K7L 3N6 Canada July 2012 Arie Van Deursen and Tobias Kuipers Building documentation generators In In Proceedings IEEE International Conference on Software Maintenance pages 40 49 IEEE Computer Society 1999 National Instruments TestStand User Manual National Instruments Corpora tion 6504 Bridge Point Parkway Austin Texsas December 1998 National Instruments Why choose ni teststand http www ni com white paper 4832 en February 2014 Last visited 17 05 2015 John McCarthy LISP 1 5 Programmer s Manual The MIT Press 1962 Leon Moonen Generating robust parsers using island grammars In Proceed ings of the 8th Working Conference on Reverse Engineering pages 13 22 IEEE Computer Society Press 2001 Eelco Visser Stratego A language for program transformation based on rewrit ing strategies In Proceedings of the 12th International Conference on Rewriting Techniques and Applications RTA 01 pages 357 362 London UK UK 2001 59
22. Addition Substraction er Exponentiate Exp i Multiply Division DIV Division f MOD Modulo MOD amp Concatenation amp Table 4 5 Mathematical and Logical Conjunctions in ATLAS and TestStand Variables in TestStand are stored in different places That is why the TestStand as sembler needs to evaluate the path of every variable Therefore a transformation in TXL is is not necessary A list of all predefined functions is included to the ARINC Spec 626 3 5 134 The functions that are transformed so far are COPY A B C to Mid A B 1 C and BITS ASCII7 A to Asc A It is not possible to call sequences from expressions in TestStand therefore custom functions can t be implemented to TestStand without a big effort At this place a work around in the future needs to be considered In most cases ATLAS custom functions implement functionalities that are already existing in TestStand pre defined functions Because the case study doesn t use custom func tions they have not been implemented 4 2 Teststand Assembler The TestStand assembler is developed in TestStand to provide the possibility to create binary sequence files This is possible because die TestStand API provides the possi Al 4 The Translator STS bility to manipulate existing persisted TestStand objects and to create new object on runtime Nevertheless TestStand primarily is a management software for automated test environments Mos
23. TUHH Hamburg University of Technology Master Thesis Sebastian Hoop Semantic Preserving Transformations from ATLAS Testcase Descriptions to Teststand Sequences June 4 2015 supervised by Prof Dr S Schupp Prof Dr R God Dipl Ing A Wichmann F Sell Hamburg University of Technology TUHH Technische Universit t Hamburg Harburg Institute for Software Systems 21073 Hamburg STS Software Technology Systems STS Eidesstattliche Erkl rung Ich SEBASTIAN HOOP Student im Studiengang Informationstechnologie an der Technischen Universit t Hamburg Harburg Matr Nr 20730088 versichere dass ich die vorliegende Masterarbeit selbst ndig verfasst und keine anderen als die angegebe nen Hilfsmittel verwendet habe Die Arbeit wurde in dieser oder hnlicher Form noch keiner Pr fungskomission vorgelegt Ort Datum Unterschrift Contents STS Contents 1 Introduction 1 1 1 Motivation s s saira oo 1 1 2 General Approach 2 0 2 0 0 0020000 1 Tid Goals ne Bede pee a Soa Gee i ge hk BAS ae ee eM Roe 2 2 Transforming Languages 4 2 1 Compiler Construction 2 0 2 e 4 2 1 1 Main Compilation Phases 4 2 1 2 Context free Grammars 2 2 004 5 2 2 Source Transformation tools 2 2 2 2m rn 7 2 2 1 The Turing eXtender Language 7 2 2 2 Additional parsing techniques 2 2 2 22 nn 10 2 2 3 More Transformation Tools 2
24. _ statement Require A_ require_ statement deconstruct list charlit Require Names list charlit deconstruct A require_type Require Type A_require_type construct T_Require repeat TeststandStatement empty where not Type isEvent Monitor by T_Require convertRequire Require each Names end rule Listing 4 4 illustrates the main transformation rule for hardware requirements The resource EventMonitor is not needed to hold events and doesn t need to be trans lated to a sequence stub In Teststand events are stored in a global container variable Therefore the constrained not isEventMonitor is included in lines 10 and 11 Because it is possible to define multiple resources with different names but the same ranges and limits the function convertRequire is called in line 13 for each virtual resource name Listing 4 5 Convert Require Function function convertRequire Require A require statement Name charlit replace repeat TeststandStatement 28 oo oa vr mw 10 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 4 The Translator STS T_Require repeat TeststandStatement deconstruct Require F A_fstatno REQURE _ list charlit Type A_ require_type Noun A noun Control A_ require_ control Capability A_require_capability _ A_ require_ limit Cnx A_require_cnx construct ConCap list A_require_body _ getBodyControl Control getBodyCapability Capabil
25. a equivalent representation in teststand Listing 4 7 If then else else if Tranformation Rules rule transform_ If replace procedural_statement F A_fstatno IF Expr repeat A expression THEN by step NI_Flow_If F If Expr transformExpressions F IF Expr THEN end rule rule transform Else If replace procedural_statement F A_fstatno ELSE IF Expr repeat A expression THEN by step NI_Flow_Elself F Elself Expr transformExpressions F ELSE IF Expr THEN end rule rule transform Else replace procedural_statement F A_fstatno ELSE by step NI_Flow_Else F Else F ELSE 33 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 4 The Translator STS end rule rule transform Leave replace procedural_statement Leave A_leave_statement deconstruct A_fstatno Leave F A_fstatno by step Leave F Leave Leave end rule rule transform End replace procedural_statement End A_end_ statement deconstruct A _fstatno End F A_fstatno by step End F End End end rule While This structure provides the possibility to repetitively execute statements as long as a certain condition evaluates to true Listing 4 8 illustrates the while transformation rule The NI Flow While ste
26. a pattern line 3 and a replacement line 5 The name serves as identifier and the type is the non terminal that the rule function transforms If the argument tree of the rule function matches the pattern the replacement is the result of the rule function In this case 2 If the argument tree doesn t match the result is the same tree again 1 2 for example Every TXL function is homomorphic and total because they always return a tree of the same type as their argument to guarantee that the transformation of an input always results in a well formed output according to the defined grammar They also always return the original tree if it does not match the pattern so they produce a 2 Transforming Languages STS result for any argument of the appropriate type 2 2 2 Additional parsing techniques When using TXL as a source to source transformation tool some parsing techniques might be useful to implement In section 3 2 1 the need for a specialisation on certain recurring parts of the ATLAS source language is discussed This means a parser is needed that accepts unknown statements and transforms them properly The tech niques to achieve that functionality are presented in this section The implementation of these techniques are shown in chapter 4 Robust Parsing The general strategy of robust parsing was originally proposed by David Barnard 2 and is based on the observation that the syntax of programming languages are basic
27. al_statement F A_fstatno FOR Counter charlit Initial number THRU End number THEN by F FOR Counter Initial THRU End BY 1 THEN end rule Perform This statement directs the program flow to a procedure The procedure is identified by a unique name It is possible to assign input values or variables and return vari ables After executing the procedure statements the program flow continues from this statement Because procedures are transformed to sequences the equivalent Test stand step is a SequenceCall Listing 4 10 illustrates the perform transformation rule Listing 4 10 Perform tranformation Rules rule transform Perform replace procedural_statement F A_fstatno PERFORM Name charlit Input A_ perform_parameters construct T_Input list A expression _ getPerformInput Input construct T_Output list A expression 35 00 10 On AUNE 4 The Translator STS _ getPerformOutput Input by step SequenceCall F Perform Name T_Input T_Output transformExpressions F PERFORM Name Input end rule Finish This statement ends the program execution immediately Because there is no direct equivalent Teststand step a number of steps are required to induce an equivalent be haviour This is explained in section 4 2 2 As listing 4 11 shows the transformation rule for the macro command is fairly simple Listing
28. ally all structured into statements These statements often have an explicit end marker like the semicolon in Java or C and the period in Cobol This observation leads to a very effective way of syntax error handling and repair strategy This strategy can be described in a few steps 1 A special recovery state is entered every time a syntax error is detected 2 Parsing is then continued in recovery state and the input is treated as if every token matches but actually is not accepted This leads to a valid parse of a program that is slightly different from the original input 3 Continue until the expected input token is a statement end marker The actual input is then flushed to this marker the recovery state can be exited and normal parsing continues The flushed input can later be caught by a syntax error routine that prompts a warning for instance This technique can be used to accept every ATLAS input program while just trans forming the parts that are actually implemented Island Grammars Island grammars implement the basic idea of robust parsing In software analysis island grammars are used for example in source model extraction 12 or when building documentation generators 8 An island grammar simply consists of the following parts 1 Detailed productions for the parts of the language that are of interest 2 Liberal productions that are catching the remaining parts 3 An elementary set of definitions that cover the overal
29. ansformation rules are applied A precise definition of the transformation rules are provided in section 4 1 At the end the generated TestStand macros are imported by the TestStand As sembler program and a runnable sequence file is created The TestStand Assembler and the macro commands are presented in section 4 2 4 1 Transformations In this section the different ATLAS structures are explained in detail The semantics are presented and the equivalent representations in TestStand as well as the rules that 26 4 The Translator STS transform the statements are explained Because there are no formal descriptions of the semantics every transformation rule is best practice 4 1 1 Preamble Preamble statements describe the structure environment and variables of the test program Hardware Resources These statements primary describe the requirements on the different hardware re sources In ATLAS these statements are also called virtual resources They define the type of hardware that need to be used as well as ranges and limits that are re quired Listing 4 2 ATLAS Require Source Example Statement REQUIRE DC SUPPLY SOURCE DC SIGNAL CONTROL VOLTAGE RANGE 0 V TO 120 V BY 0 01V ERRLMT 0 01 V CAPABILITY CURRENT MAX 1 2 A LIMIT CURRENTIMT MAX 1 A CNX HI LO Listing 4 2 shows a typical ATLAS require statement The resource requirements are always divided into control capability limit and cnx co
30. at can be found in the report of the translated TestStand program and the amount of teststeps in the TestStand Report that show correct limits The comparison of the reports shows that all teststeps appear in the right order in TestStand Nevertheless two errors have been identified One teststep in chapter 2 8 and 3 8 in the TestStand Report did not retrieve the same limits as the ATLAS reference report This can be associated with an error in the ATLAS source code and does not imply a flawed translation Figure 5 1 shows the deficient teststep from chapter 2 8 The comment line of the test step shows the translated ATLAS statement for comparison Clearly the limits for the upper and lower bound were interchanged Figure 5 1 Interchanged Limits In chapter 2 9 and 3 9 a teststep in the TestStand Report went missing This problem could be attributed to a defective implementation of the value query Figure 5 2 shows the associated TestStand code An If statement retrieves the boolean vari able MAX TIME According to this another variable is set to TRUE or FALSE To generate an entry in the report a COMPARE Statement should check the variable MAX TIME for TRUE in the correct implementation This error can therefore not 51 5 Evaluation STS Chapter ATLAS TestStand Number of number test steps test steps correct tests 1 0 2 2 2 2 1 25 25 25 2 2 148 148 148
31. ation wiki http www program transformation org Stratego Stratego 13 is a modern language aimed at the specification of program transforma tion systems based on the paradigm of rewriting strategies Stratego adapted an idea from Elan 3 deduction meta system and uses pure rewriting rules with the separate specification of generic rewriting This separation allows careful control over the ap plication of these rules and allows transformations rules to be reusable in multiple different transformations It also lead to a more compact and modular transformation specification compared to TXL 11 2 Transforming Languages STS ASF SDF ASF SDF 4 is a toolset for implementing many programming language manipula tion tools like parsers and transformers that is very different from TXL in its meth ods and implementation It uses a GLR parsing algorithm providing grammar based modularity and supports the specification of patterns in concrete syntax 12 3 Test Language Transformation STS 3 Test Language Transformation 3 1 Test Software for Automatic Testing This section introduces the source and target language and presents the environment they are usually used in 3 1 1 ATLAS The Language for all Systems The ATLAS test language was developed by the Aeronautical Radio Inc ARINC to satify the desire for an application and documentation language for manual and automatic testing in airline avionics The Development s
32. because they are always copied to the post expression part of the Teststand step This means unknown expressions are automatically caught by the Teststand built in syntax check e Unknown variable or resource declarations lead to variables and resources that can not be assigned during an assemble phase These cases result in Teststand steps that are not considered in the table even if they are not running properly This implies that the percentage of not running code is probably higher Nonetheless can the results be predictive of the transformed code because the expressions only represent a small fraction of the errors Furthermore adding the not declared variables and resources automatically corrects the allocation errors in other steps The test system is therefore robust and can be used in this setup to save time 5 2 Case Study The following case study validates the transformation system regarding the proper semantic As mentioned in section 3 2 2 the semantical correctness is ensured if the test report of the transformed test programs equals the test report of the original test program Saying that both reports have to make the same predictions about the UUT To verify the semantical correctness of the transformation rules the rule set and grammar was supplemented to convert 100 of the code lines of an example program The OEM ATLAS Programm consists of 19 Testchapters The UUT consists of two identically constructed components wh
33. cused on true rapid prototyping with no generation or build steps This led to the decision to choose the functional programming language Lisp 11 as the model for the underlying semantics of TXL because of the following reasons e One simple data structure nested first rest lists Fast interpretive full backtracking implementation well suited for rapid proto typing e Implementation is heavily optimised for list processing Therefore Lisp structures provide the foundation for many design decisions of TXL early on This leads to a parsing model with a top down functional interpretation of the grammar The start symbol is the non terminal program The grammar is directly interpreted as a recursive functional program that is consuming the input as a list of terminal symbols The structure of each TXL grammar consists of two kinds of lists 1 A choice list for alternation 2 An order list for sequencing The interpretation of alternate form in choice lists is the order they are presented in the grammar The first matching alternative is taken as a success The representation in lists highly favours backtracking while parsing If a choice alternative or sequence element is failing the algorithm simply backtracks one element of the list to try the next alternate form At the end the result is a parse tree that is represented in the same nested list representation like every TXL structure grammar parse tree rules patterns and rep
34. d to and if they are implemented yet Due to the limitations on TestStand variable types it is not possible to find equivalent variable types However this is not required to achieve a semantically equivalent result in an avionic test environ ment Below the different ATLAS variable types and their TestStand counterparts are discussed 1 Enumeration Enumerations are not implemented to Teststand However it is possible to utilize the Container structure that is comparable with a struct in C to ac complish a similar result Pre declared ATLAS enumeration types are Boolean Char Class and Dig Class While Boolean has an equivalent counterpart in TestStand Char Class and Dig Class can be translated like any other enumer ation 2 Connection Connections are used to identify hardware pins of the UUT in ATLAS Because hardware control is not in the scope of this work it is sufficient to save the con nection name in a string variable and hand them over to the hardware sequence which will handle the connections of instruments to the corresponding pin 3 Decimal Integer and Bit Numeric variables are entirely translated to the TestStand Number type The default representation is a double precision 64 bit floating point variable and it is possible to change the representation to a signed or unsigned 64 bit Integer but it is not possible to change the precision any further So the intentional usage of a wrap around need to be considered but is not ex
35. ep code modules limit checking user management report generation or result collection TestStand highly utilises modules that are written in separate development lan guages for measurement code or individual test actions With a set of adapters allowing to call code modules written in a variety of languages it is even possible to mix different programming languages in one test sequence The current build in adapters link with Labview LabWindows CVI C C NET ActiveX COM and HTBasic Operator Interface Programs with Full Source Code Sequence Editor LabVIEW Visual Basic Process Model TestStand Engine Adapter Interface Load Unload Execute Step Into Create Code Edit Code LabVIEW C CVI DLL Standard Standard Flexible Prototype Prototype Prototype Adapter Adapter Adapter ActiveX Automation Adapter Sequence Adapter Sequence Files Figure 3 5 TestStand System Architecture from TestStand User Manual 9 1 4 Figure 3 5 illustrates the TestStand system architecture Major software compo 18 3 Test Language Transformation STS nents of TestStand include the TestStand engine Sequence editor Operator interface and module adapters The essential part of the TestStand system architecture is the engine The TestStand engine runs sequences that contain different steps Steps can call external code modules utilising the standard adapter interface This interface is also used by sequences
36. erent combinations it seems impossible to control the semantics of the transformation process for all possible inputs As stated in Section 3 2 1 there is a no need to transform the whole source language but to focus on the important aspects To specify only the semantics of those parts that ought to be transformed must prevail This way the problem can be separated in different parts and individual solutions for specific transformations should be considered But what are the really important parts of the program 23 3 Test Language Transformation STS The output of a test program is a report which summarizes the test results This report helps a technician to decide if a tested UUT is operational or not If one includes the user the output can be defined as the reaction of the technician on the report Therefore it is important that the technician can come to the same conclu sion not that both reports look exactly the same Some informations are particularly important for the equivalence of the output in the report So how does a report like this look like The key components of a test report are the informations that are available for every single step e The distinct Test Step Number TSN for the precise identification of the test steps e A short description of the test steps or the key components of the test steps like relevant pins e The measurement or the value for the comparison e The limits in which the measu
37. ew Statement step and forwards the object reference to the NewStep variable 2 Creates a command in the subproperty PostExpression so that the step can set his own status to Passed on run time 3 Manipulates the subproperty PassAction and sets the value to Terminate 4 Sets the step name 46 rw 4 The Translator STS 5 Forwards the corresponding ATLAS code as a comment 6 The variable FileGlobals ActualSequence holds a reference object to the sequence to write to The API command InsertStep inserts the step into the sequence Listing 4 16 Using TestStand API to build a new Step Locals NewStep RunState Engine NewStep Statement Locals NewStep AsStep PostExpression RunState Step Result Status Passed Locals NewStep AsStep PassAction Terminate Locals NewStep AsStep Name Trim Locals Steparray 2 Locals NewStep AsPropertyObject Comment Str Locals Steparray 3 FileGlobals ActualSequence AsSequence InsertStep Locals NewStep FileGlobals ActualSequence AsSequence GetNumSteps StepGroup_ Main StepGroup_Main PassAction is implemented in every step and controls what ought to happen after the step when the status of the step is Passed Usually the next step in line is activated but in this case the program is shut down Because the statement can manipulate its own status on runtime with the help of the TestStand API the termination of the test pr
38. f Electrical and Electronics Engineers LHT Lufthansa Technik AG NI National Instruments OEM Original Equipment Manufacturer TSN Test Step Number TUA Test Unit Adapter TXL Turin eXtender Language UUT Unit Under Test List of Figures STS List of Figures 1 1 Basic source transformation concept 2 2 22 2 nn nn 2 2 1 TXL Processor 8 3 1 Standard ATLAS Statement Structure 00 14 3 2 ATLAS Program Structure 0 0 0000 eee eee 14 3 3 ATLAS Preamble Structure 15 3 4 ATLAS Procedural Structure 0 0 a 17 3 5 TestStand System Architecture from TestStand User Manual 9 1 4 18 4 1 Transformation Concept 25 4 2 ATLAS Procedures 2 28 25 2 0 8 0 8 8 5 a8 Re a a 30 5 1 Interchanged Limits 2 Co Con nn 51 5 2 Incorrect Variable Monitoring 2 2 2 2 Ko nn 53 5 3 Hardware Timing Problem 2 222 Con nn 54 vi 1 Introduction STS 1 Introduction This work transforms ATLAS test cases to TestStand sequences using TXL In con sideration of preserving the semantics the test software is migrated into TestStand using robust parsing techniques and the method is evaluated by means of a case study 1 1 Motivation All modern aircraft types consist of many electronic flight computers a Fly By Wire system The aircraft manufacturer like Airbus and Boeing are subcontracting the development and production of these components so an airline has to deal with lots of companies
39. for calling subsequences The TestStand Sequence Editor represents the development environment It gives access to all TestStand features Sequences can be created edited executed and debugged The built in debugging tool is capable of setting breakpoints Stepping into out of and over steps tracing through program executioins monitoring variables and expressions during execution and performing an analysis of the sequence file to locate errors The TestStand Operator Interface provide the possibility to create a custom Graphical User Interface GUI for executing debugging or editing developed in any programming language that can host ActiveX control or control ActiveX Automation servers The TestStand Engine is a set of DLLs that provide access to the ActiveX Automa tion Application Programming Interface APT that can be used to create execute edit and debug sequences This API is used by the sequence editor and Operator Interface and can be called by any programming environment that supports ActiveX Automation Servers Module Adapters are used to invoke code modules that are called by sequences A code module contains various functions that perform actions or specific tests The following adapters are included e LabView Calls Labview VIs e LabWindows CVI Calls C functions in a DLL e C C DLL Calls C C functions and static C class methods in a DLL e NET Calls NET assemblies e ActiveX COM Calls methods and accesses pro
40. he kind of variable and Location states the storage location So far these types are implemented e number e string e container Also variables for custom types can be forwarded storage locations can be e Locals Inputparameter e Outputparameter e FileGlobals e Exchange 45 4 The Translator STS Edit With this category one can manipulate existing structures or save typedefs edit Begin Program name edit Terminate Program name Mark the beginning and the end of the ATLAS program and therefore don t have any impact on the program Only the Program name is analysed and compared edit Variable Name Initial Variable values can be changed further in the process edit Type Name Type Adds a custom type to the global variable fileGlobals Types with the name Name and the predefined type Type 4 2 2 Construction Examples This section illustrates the implementation of some of the macros with the help of exemplary code from the TestStand Assembler The specific commands are processed top down Finish Because Teststand does not have a dedicated step to end a test run a statement step is induced to accomplish this This particular example shows the general use of the TestStand API Listing 4 16 illustrates the API commands that are executed in the Create New Finish Statement step depicted above The effect of each code line is explained in the following 1 Creates a n
41. icture the whole ATLAS syntax but the most common parts used in avionic test programs suggests itself The problem with this approach is that an incomplete grammar will lead to syn tax errors while parsing Therefore the robust parsing technique described in section 2 2 2 is needed The implementation of such a technique is supported by two factors 1 ATLAS programs exclusively consists of code lines that follow the standard statement structure given in section 3 1 1 on page 13 2 TXL grammars allow ambiguity The parsing algorithm takes the first matching alternative in the list as a success This means providing a statement that matches every input that has the standard ATLAS structure at the end of the list will catch all ATLAS statements that aren t defined To implement robust parsing to TXL the non terminal A_ unknown_ statement is introduced Listing 3 1 shows the unknown statement definition The general structure represents the standard ATLAS statement structure A Statement number followed by a ATLAS verb followed by a comma is accepted by the parser The non terminal A_ remainder than accepts every input except the statement terminator Listing 3 1 Unknown Statement Definition 1 define A_unknown_ statement 22 w soon aoavr A 10 12 13 14 3 Test Language Transformation STS GENERAL ATLAS STATEMENT STRUCTURE A_ fstatno A verb j A_ field_ separator repeat A_remainder end defi
42. ign a grammar pseudo language that can be read by the assembler program e Evaluation Test the transformation system on different inputs and compare the results Evaluate the output of one case study by comparing the results of both programs 2 Transforming Languages STS 2 Transforming Languages In this chapter the techniques of source transformation are introduced The typical application for source transformation is a compiler In section 2 1 the basics of com piler construction are explained and the techniques and tools that are useful for this work are introduced 2 1 Compiler Construction Simply stated a compiler is a program that can read a program in one lan guage the source language and translate it into an equivalent program in another language the target language l Usually the target language for compilers is a low level language like Assembler or even machine language In this work the source and the target language are high level development languages but the basic principles are the same so the techniques of compiler construction can be adopted 2 1 1 Main Compilation Phases In general the work flow of a compiler can be divided into multiple phases In the following the major parts are illustrated e Lexical analysis A Lexer reads the high level source code and chops its char acters into meaningful tokens e Syntax analysis A Parser reads this string of tokens and groups them into a par
43. irements is designed to transport the test specification from implementation on one set of test equipment to another The ATLAS program structure basically consists of variables and statement syn tax A standard ATLAS statement consists of a flag field F statement number field STATNO verb field VERB field separator statement remainder REMAIN DER and statement terminator arranged in Figure 3 1 Figure 3 2 illustrates the standard ATLAS program structure Every ATLAS pro gram starts with a begin atlas statement and ends with a terminate atlas statement 13 3 Test Language Transformation STS F STATNO VERB REMAINDER Figure 3 1 Standard ATLAS Statement Structure The commence main procedure statement separates the two main elements program preamble structure and main procedural structure main 3 3 sta 3 statement Figure 3 2 ATLAS Program Structure The program preamble structure consists of statements that do not cause any tests to be executed but the information contained in the structure is used by the state ments in the main procedural part Figure 3 3 on page 15 illustrates all ATLAS preamble statements defined in the ARINC Specification 626 3 5 In the following these statements are briefly described Include statements reference to ATLAS modules that may be used in multiple test programs These modules contain non ATLAS code that may be loaded into a UUT or often used preamble statements
44. is step represents ATLAS statements that are not necessary for the correct execution of the test program step NI_Flow_If Statement number If Condition ATLAS code step NI_Flow_Elself Statement number If Condition AT LAS code step NI_Flow__While Statement number While Condition ATLAS code Creates an If Elseif While step At the Condition variable the condition expression is assigned step NI_Flow__For Statement number For Loop variable Start number Number of loops Increment value ATLAS code Creates a For step The Loop variable represents the variable where the Index of the for loop is stored The Start number variable indicates with what number the Loop variable is initiated The Number of loops is the upper limit and the Increment value variable indicates the incrementation number step End Statement number End ATLAS code Creates an End step which marks the end of an if for while structure step Leave Statement number Leave ATLAS code Creates a Break step that allows to jump out of if for while structures step Report Statement number Message Text output ATLAS code Creates a VTSA__PostText step to print text into the report The variable Text output contains the actual text but can also contain additional variables that have to be mapped by the Assembler step MessagePopup Statement number Me
45. ity construct T variables repeat T_ variables variable Action String Inputparameter variable Return Number Outputparameter construct newRequire TeststandStatement sequence BuildSequence Name Hardware sequence SetSequence Name T_variables getRequireVariables each ConCap getRequireCnx Cnx getExtraVariables Noun sequence ResetSequence by T_Require newRequire end function The function convertRequire shown in Listing 4 5 constructs the macros needed to build a new hardware sequence To get the remaining instruction parameters that are needed for later sequence calls the require statement is deconstructed in lines 5 9 The control capability and connection information are stored in the variables Control Capability and Cnz The functions getRequire Variables and getRequireCnz in lines 21 and 22 are extracting the instruction parameter names from the variables and construct the corresponding variable macros The function getExtra Variables covers the fact that a time interval also needs the parameters from to and max time The macro commands SetSequence and ResetSequence in lines 20 and 23 make sure the assembler puts the variables into the right sequence Procedures and Functions These structures contain ATLAS code that is often used in the program flow In put and output
46. l program structure 10 2 Transforming Languages STS General speaking an island grammar consist of constructs of interest the islands and parts that are not interesting for the developer the water Union Grammars Unlike the language extension tasks for which TXL was designed source to source transformation requires transformations to deal with two language grammars the source language ATLAS and the target language TestStand Hence TXL rules are constrained to be homomorphic it could be problematic to solve this kind of multi grammar task The solution is union grammars The basic paradigm for union grammars involves the following steps 1 Create working grammars for both the target and the source language 2 Uniquely rename the non terminals of the two grammars 3 Identify a minimal set of corresponding non terminals to be used as transfor mation targets 4 Restructure and integrate the source and target grammars to form an integrated translation grammar 5 Build a set of independent translation rules for each corresponding non terminal 2 2 3 More Transformation Tools Source transformation is a great field of research Although there are a lot of source transformation tools most of them are not designed to migrate two languages but they are still good to meet this task In the following few of them are presented Many other source transformation tools and languages can be found on the program transform
47. lacements TXL also addresses the difficulties with left recursion in top down parses by switching to a bottom up interpretation of these productions on the fly Figure 2 1 illustrates the the compiler and run time system for the TXL language The TXL processor directly interprets the TXL programs that are consisting of the grammar and the transformation rules and functions QANE 2 Transforming Languages STS TXL Program Structural Transformation Rules TXL Processor Output Figure 2 1 TXL Processor The grammar The Source language to be transformed is described using an unrestricted ambiguous context free grammar in extended Backus Naur Form BNP from which a structure parser is automatically derived The basic notation is as follows e X terminal symbols represent themselves e X non terminal types appear in brackets e the bar separates alternative syntactic forms Listing 2 1 shows an example TXL grammar The key unit is the define state ment Each define statement represents an ordered set of alternative forms for one non terminal This set can be compared with a set of productions for a single non terminal in a BNF grammar Each alternative form is specified as a sequence of terminal symbols and non terminals In case of the example grammar the terminals shown are The non terminal number in line 18 is a special predefined non terminal representing any unsigned integer or real number
48. lculate statement evaluates an expression on the right side of an equals sign and assigns the value to the variable on the left side of the equals sign It is possible to make more evaluations by separating each assignment by a comma This functionality can be provided by a statement step in TestStand Every evaluation assignment pair can be written in the post expression property and is conveniently also separated by a comma Listing 4 13 Transform Calculate Rule rule transformCalculate replace procedural_statement F A_fstatno CALCUALTE Expr repeat A_ expression by step Statement F Calcualte Expr transformExpressions F CALCUALTE Expr end rule Listing 4 13 shows the transformation rule for calculate statements The replace ment rule is straight forward so only one subrule to transform the expressions is needed This means the main challenge is to translate these expressions properly For further information about expression transformation see section 4 1 5 on page 40 In the scope of this work the expression transformation is just focused on the expressions we encountered in the example code So in future work the complete transformation of the expressions is recommended Compare This statement compares a variable with the limits defined in an evaluation field This comparison and the results are then printed to the report The equivalent Teststand step is the VTS
49. ls can be combined to form strings The pictorial representation of how the start symbol of a grammar derives a string in the language is a parse tree If a non terminal X has a production ABC the parse tree would have an interior node named X and three children from left to right named A B and Formally a parse tree according to a context free grammar is a tree with the fol lowing properties given that e is an empty string 1 The root is designated by the start symbol 2 Each leaf is designated by a terminal or by e 3 Each interior node is designated by a non terminal 4 If the non terminal X is designated by some interior node and X1 X2 Xn are the labels of the children of that node from left to right then there must be a production X gt X1Xa Xn X1X2 X can either be a terminal or a non terminal If X gt e is a production than a node designated by X may have a single child designated by e If a grammar has more than one parse tree generating a given string of terminals it is said to be ambiguous This is shown by finding a terminal sting that is the yield of more than one parse tree So an unambiguous grammars for compiling applications need to be designed or an ambiguous grammars with additional rules to resolve the ambiguities to be used since a string with more then one parse tree usually has more than one meaning 2 Transforming Languages STS From the parse tree view point there are two maj
50. n the Translator Like in any other language the two key components of ATLAS and TestStand are syntax and semantics That means the structure of the language how symbols are 21 3 Test Language Transformation STS ordered and what symbols to expect and the actual meaning of each symbol or set of symbols In this section the requirements on the grammar according to the syntax are discussed as well as the demands on preserving the semantics 3 2 1 Parsing ATLAS Syntax The first task to accomplish is How to design the grammar for parsing the source language ATLAS Section 3 1 1 shows ATLAS has grown to a very wide test language used in a great number of automatic testing environments This means that not ev ery aspect of the test language is necessary for testing avionic devices So parts of the syntax might never be used Because there are only two major companies building aircraft s the number of companies developing test programs for avionic equipment is also fairly manageable So there are not a lot developers writing new ATLAS code It is quite possible that developers rather reuse already existing code than write new test programs from scratch This leads to the assumption that most parts of the test software does not differ very much in terms of the structures that are used Given that developing a grammar that successfully parses every aspect of the ATLAS language is a very time consuming task building a grammar that does not p
51. nal deconstruct charlit Noun Requirename charlit deconstruct Cnx CNX Pins repeat A_ Pins construct Verbid id _ unparse Verb construct Return A body_remainder 0 construct Parameters repeat T_signal_body Action Verbid Return Return getReturnValue Mes by step SignalCall F Verbid Requirename Parameters getSignalParameterBody each Body getSignalParameterCnx each Pins F Verb Mes Noun Body Cnx _ end rule 4 1 5 Expressions An expression consists of one or more expression items that are links via a mathemat ical boolean and or logic operator Table 4 5 shows the different possible operators and their equivalent counterpart in TestStand Most of these operators are expressed in the same way in ATLAS and TestStand That means that a lot of the parts of an expression don t need to be transformed at all An expression item may be one of these for items e predefined or in preamble defined function e another expression in parenthesis e A variable e a constant 40 4 The Translator STS ATLAS Description Teststand Operation equivalent EQ Equality or EQ NE Inequality or NE GT Greater than gt or GT LT Less than lt or LT GE GT or EQ gt or GE LE LT or EQ lt or LE XOR Exclusive OR XOR OR Logical OR OR AND Logical AND AND NOT Logical NOT NOT
52. ne define A_ remainder Bounded by terminal symbol not token_or_key end define define token_or_key TXL idiom for any input token key end define Every unknown statement can than be transformed to a special TestStand step that displays the unknown code line in the TestStand program A developer might transform these steps later by hand or the transformation system can be extended to transform that statement properly 3 2 2 Preserving Semantics in Avionic Environments Preserving the semantics of the test software is an important part of the transfor mation system The problem in this work is that the semantics of nether ATLAS nor TestStand are formally described But proving semantically correctness is nearly impossible with no formal descriptions of the source and target language Developing these formal descriptions is also not an option Besides the immense amount of time this would cost the semantics described in the ARINC specification 5 are not precise enough to deviate formal structures We will therefore take a practical approach If the source program A and the trans formed source program T get the same input they have to produce the same output First we will define the input and output of A and T In automatic test environments the possible input consists of all signals that come from measurement equipment and the tested UUT and also possible user input With the huge amount of data in diff
53. nnection parameters The virtual resource DC SUPPLY represents a DC voltage Source with a range from OV to 120V adjustable in 0 01 V steps with an accuracy of 0 01V and the capability of a current of 1 2 A maximum It also needs the ability of limiting the current to maximum 1 A The proper example of use is shown in Listing 4 3 The virtual resource DC SUPPLY is used with the instructions illustrated in Table 4 1 Line Instruction Value 1 Control action APPLY 2 Voltage 18 7 V 3 Current max 0 5 A 4 Connection HI J1A 30 5 Connection LO J1A 03 Table 4 1 Example APPLY Statement Instructions 27 oF WN m OOnNnroankwner Rth e w N Ho 2 4 The Translator STS Listing 4 3 ATLAS Apply Example Statement APPLY DC SIGNAL USING DC SUPPLY VOLTAGE 18 7 V ERRLMT 0 01 V CURRENT MAX 0 5 A CNX HI J1A 30 LO J1A 03 The Transformation of hardware resources is reduced to just creating the Teststand sequence stub Filling these stubs with actual hardware control instructions is out side the scope of this work since an engineer needs to select the hardware that is available at the test facility However the instructions need to be transferred to the hardware sequence when calling it later on Therefore the sequence needs to feature the parameters established in the requirement definition Listing 4 4 Transform Require Rule rule transformRequire replace preamble
54. o are both tested in the same way Therefore the test chapter 2 x and 3 x are always identical but refer to different pins on the UUT Every test chapter consists of different steps that can be identified with a distinct Test Step Number TSN This number can be found in every step of the Testreport Therefore the TSN can be used in our case study as an identification mark to compare the results Every Teststep can therefore be identified and compared precisely 50 5 Evaluation STS 1 The Teststeps have to come up in the exact same order in both reports 2 Each test step with the same TSN has to run the same test 3 Every test with the same TSN has to retrieve the same limits 4 Ina Test with the same UUT Teststeps with the same TSN have to deliver the same result measured 5 2 1 Limits To compare the program structure and measurement limits the translated exemplary program is executed without the hardware first The program generates a report with out measured values but with every Teststep included That report is than compared with a reference report from the ATLAS source program This allows to control for missing teststeps and if the teststeps are in the right order while testing if the correct limits were prompted Therefore the structure of the translated testprogram can be validated Table 5 2 shows for every chapter the amount of teststeps that are mentioned in the reference report the amount of teststeps th
55. odules and removes comments To ease the parsing process dimensions are moved away from numerical values 5V 5 V and decimal numbers less than 1 are corrected 1 0 1 The generated input file is then parsed with TXL into a tree structure Listing 4 1 shows the basic grammar structure The non terminal define program marks the start symbol A_ preamble_statement and A_ procedural_ statement are the non terminals that include a choice list of all essential statement definitions At the end of each list the unknown statements are intercepted 25 4 The Translator STS Listing 4 1 Basic ATLAS grammar structure define program A_begin_atlas_statement repeat preamble_statement A_commence_ statement repeat procedural_statement repeat block structure A _terminate_atlas_statement end define define A_preamble_statement A_ extend_ statement A_require_statement A_declare_statement A_establish_statement A_define_statement A_identify_statement A_ unknown _preamble_ statement end define define A_procedural_statement A_declare_statement A_calculate_statement A_compare_statement A_output_statement A_input_statement A_flow_control_statement A remove statement A_signal_ statement A_ do_ exchange_ statement A_ subchapter_ begin A_subchapter_end A_unknown_procedural_ statement end define After converting the input file to a parse tree structure the TXL tr
56. ogram is ensured This steps looks like shown below The row 999998 FINISH shows the comment field and the associated ATLAS code For Another example is the creation of a For Step As mentioned in Section 4 2 1 this step contains a Loop variable Because it is unclear at that moment where this variable is stored it has to be searched for inside the program Because of this the sequence locate Variable as shown below is accessed and the name of the variable forwarded 7 Case NI_Flow_For R locate Variable Call locate Variable in lt Current File gt Listing 4 17 illustrates the API calls of the step Create New For Statement The sub properties InitializationExpr ConditionEzpr IncrementExpr and CustomLoop are no standard subproperties which every step has therefore they have to be manipulated via SetValString respectively SetValBoolean 47 4 The Translator STS Listing 4 17 Building a For Step using the TestStand API Locals NewStep RunState Engine NewStep NI_Flow_For FileGlobals ActualSequence AsSequence InsertStep Locals NewStep FileGlobals ActualSequence AsSequence GetNumSteps StepGroup_Main StepGroup_Main Locals NewStep AsPropertyObject SetValString InitializationExpr 0 Locals Steparray 3 Locals Steparray 4 Locals NewStep AsPropertyObject SetValString ConditionExpr 0 Locals Steparray 3 lt Locals Steparray 5 Locals NewStep AsProper
57. or parsing techniques to consider It is convenient to describe parsing as the process of building parse trees although a front end may in fact carry out a translation directly without building an explicit tree Top down parsing Top down parsing constructs the parse tree for the input string starting from the root and developing the nodes depth first Alternatively top down parsing can also be seen as finding a leftmost derivation for an input string The key problem for each step of a top down parse is that of determining the production to be applied for a non terminal For example using the general recursive descent parsing approach If a production for non terminal X is chosen the rest of the parsing process consists of matching the terminal symbols in the production body with the input string If the input string doesn t match backtracking might be required Predictive parsing is a special case of recursive descent parsing The correct X production is chosen by looking ahead at the input a fixed number of symbols This class of grammars is sometimes called LL k class where k is the number of symbols the parser in looking ahead Bottom up parsing Bottom up parsing is approaching the problem as the name may reveal from the other way around The construction begins at the leaves and is working up towards the root This process man also be seen as reducing a string P to the start symbol of the grammar This means at each reduction step
58. p is the equivalent representation of the WHILE state ment Listing 4 8 While Tranformation Rules rule transform While replace procedural_statement F A_fstatno WHILE Expr repeat A_ expression THEN by step NI_Flow_While F While Expr transformExpressions F WHILE Expr THEN end rule For This structure provides the possibility to repetitively execute statements for a defined amount of iterations Because the Teststand NI_Flow_ For step is equivalent to the 34 al N oO COND 11 12 13 w al 4 The Translator STS ATLAS FOR statement the counter variable initial value increment value and max imum value are just handed over to the macro assembler Listing 4 9 illustrates the for transformation rule If the increment value is not defined it is set to 1 by default in ATLAS Therefore the convert _Default_For rule manipulates the ATLAS code to match the replacement condition of the transform__For rule Listing 4 9 For Tranformation Rules rule transform_ For replace procedural_statement F A_fstatno FOR Counter charlit Initial number THRU End number BY Increment number THEN by step NI_Flow_For F For Counter Initial End Increment F FOR Counter Initial THRU End BY Increment THEN end rule rule convert Default For replace procedur
59. pected in avionic testing 31 4 The Translator STS 4 Char A char represents a single character TestStand doesn t contain variable types that represent a single character this is why a char is transformed to a string 5 Array An array is a data structure consisting of a collection of elements that can be identified by an index This structure also exists in TestStand Therefore it can be translated directly However arrays are not very common in ATLAS test programs and are not used by the case study This is why arrays are not implemented yet 6 String of Type A string of type basically is the same as a TestStand string with the exception that the characters of the string are more precisely defined Because the ATLAS source code is considered to be faultless it is not expected that wrong characters are stored in this variable This is why the TestStand string type is considered to be equivalent 7 Record and File These data types have no equivalent counterparts in TestStand but are seldom used It is recommended to find a work around with a NI LabView VI or a C dll ATLAS type Teststand type Implemented Enumeration Number Container Connection String Y Decimal Number Y Integer Number Y Char String Y Bit Number Y Boolean Boolean Y Char Class Number Container Dig Class Number Container Array Array String of Type String Y Record
60. perties of ActiveX COM objects e HTBasic Calls HTBasic subroutines e Sequence passes parameters when calling subsequences The Graphical User Interface of TestStand provides the developer with various building blocks In the following an overview of the different TestStand blocks and features are given In TestStand the places that store data values are called variables and proper ties Variables can be created in certain contexts They can be global to a sequence 19 3 Test Language Transformation STS file local to a certain sequence or station global to the computer the program is run ning on Properties are containers of values They can contain just a single value an array of values or various subproperties Steps in sequences can store values in properties The properties of steps are determined by the type of the step Any TestStand sequence contains multiple steps They can perform a variety of tasks through several types of mechanisms A step is capable to execute an expres sion call a subsequence or an external code module The step properties are used to store parameters to pass to the code module or serve as a place for the code module to store the results These properties are called custom properties and are different for each step type TestStand steps also have a number of built in properties The Precondition property for example allows the specification of conditions that must be true to execute the step The P
61. ptance of incor rect syntax Therefore it was assumed for this work that the source code is error free However the run test has shown that the ATLAS test descriptions contained multiple errors These errors were most likely fixed in the test software of the manufacturer but not in the ATLAS test case descriptions of the CMM The source transformation tool TXL has proven to be extremely solid The trans formations have taken no longer than one minute even when using source code with many code lines and unknown statements Considering it takes the TestStand As sembler 20 to 30 minutes afterwards to construct the sequence files the time the transformations take are even less significant However if the grammar is still signif icantly expanded and there are a lot of unknown statement the backtracking could cause the main memory to overflow Copy from string A at index B a substring with length C 56 6 Conclusion STS 6 1 Future Work During the work on the project some promising ideas had to be discarded due to time restrictions and the evaluation process exposed some weaknesses in the transformation system The following suggestions show great potential to improve the capabilities of the transformation system e The Teststand Macro Assembler could be extended to support the creation of a Report to ease the transformation process Information about unused or undefined variables and unknown statements are a great help during
62. quences 70 to 90 of the code lines of each individual translated program do not subsequently have to be revised by hand This supports the assumption that large parts of the ATLAS test case descriptions are developed with small amounts of the available features the ATLAS language provides The face that after transformation at most 30 of the code lines of the source program need to be reviewed by hand promises significant time savings in the migration process This can certainly be improved by an extension of the grammar and the transformation rules During the run test we could also identify two weaknesses of the transformation systems A major source of error are the descriptions of the ATLAS semantics in the ARINC specification 626 3 5 These have proved to be not as precise as claimed 55 6 Conclusion STS by the authors Especially the descriptions of pre defined ATLAS functions are am biguous and incomplete For example in the description of the ATLAS function COPY A B C the information that the index starts at one is missing That has caused the index in the transformed TastStand program to be off of one digit because the index of the nearly equivalent TestStand function Mid A B C starts at zero Another major source of error are the ATLAS test descriptions themselves The transformation system is not capable of identifying semantic errors in the program code The robustness of the grammar sometimes also causes the acce
63. re Postexpression property allows the specification of an expression to evaluate before after the execution of the step The number of custom properties a step has is determined by the step type Every step of the same type has the same custom properties in addition to the built in properties The pre defined TestStand step types are as follows e Action e Numeric Limit Test e String Value Test e Pass Fail Test e Label e Goto e Statement e Limit Loader e Message Popup Call Executable e Sequence Call In addition the test environment at Lufthansa Technik AG extend this set of types by a number of custom steps e VTSA Numeric Limit Test e VTSA Hexadecimal Limit Test 20 3 Test Language Transformation STS e ChapterCall e VISA Post Text to Report Any TestStand sequence consists of local variables parameters steps and built in properties Sequence parameters are variables that store values passed by a sequence call step It is possible to pass parameters by value or by reference to any step in the sequence Local variables store values that are relevant for the execution of the sequence They apply only to the sequence they are created in It is possible to run multiple instances of the same sequence for example by calling this sequence recur sively In this case each instance of the sequence has its own parameters and local variables 3 1 3 Automatic test environments Automatic test environments ATE are used
64. rement was compared to create the test result e A conclusive result of the test GO or NOGO It is very important that these informations are being ensured during the trans formation pocess and can be found in the TestStand program An important part of the program is therefore the report generation In ATLAS the relevant statements are the data processing statements CALCULATE and COMPARE as well as INPUT and OUTPUT Another significant part of a developing language is the program flow Executing the statements in the same order is essential for the program semantics In ATLAS these statements are If then else structures procedures and functions An othert important aspect in automatic test languages is the hardware triggering the requirements to the hardware components as well as the commands to control them The rules of transformation of these components will be illustrated in chapter 4 24 4 The Translator STS 4 The Translator The transformation system is capable of parsing any ARINC 626 3 Spec ATLAS source code and converting it into TestStand sequences Thanks to the robust gram mar not implemented ATLAS statements can be transferred to the TestStand se quences without causing syntax errors Figure 4 1 illustrates the schematic structure of the transformation system Figure 4 1 Transformation Concept Initially a small program merges all ATLAS source files into one input file This step mainly includes integrated m
65. se tree e Semantic analysis A code generator converts the parse tree into a list of machine instructions Theses steps can also be found in source to source transformation The key com ponents are a well defined parser grammar and a code generator that does not violate the semantics of the source program Many compilers also have the ability to identify and correct syntax failures or optimize the code This is out of the scope of this work but might be a possibility for future work Syntax analysis There are two ways to describe a programming language The first way is to describe its semantics What each program does when its being executed The second way 2 Transforming Languages STS is to describe the proper form of a programming language the syntax Contex free grammars or Backus Naur Form BNF are widely used to specify the syntax of a programming language 2 1 2 Context free Grammars A context free grammar basically consists of four components 1 A set of fundamental symbols of the language defined by the grammar These symbols are called terminal symbols or tokens 2 A set of non terminals that each represent a set of strings of terminals 3 One of the non terminals assigned to be a start symbol 4 A set of productions that each consist of a head a non terminal and the body of the production a sequence of terminals and or non terminals Productions specify the manner in which the terminals and non termina
66. sformation are very high Especially in avionic systems preserving semantics is very important to approve safety and governmental restric tions among others This means we need a robust and reliable transformation system Figure 1 1 illustrates the basic concept of the transformation approach The process can be divided into 4 different phases 1 Introduction STS LAS ests ATLAS Teststand eea Parse transformation Parse unparse we assemble Teststand acre Tree Tree Figure 1 1 Basic source transformation concept Parsing The parsing phase is very similar to parsing done in a compiler 1 A formal structure in form of a grammar is introduced to describe the ATLAS language and parse it into a tree structure for later transformation It is important to build the grammar as precise as possible to avoid ambiguity and prevent syntax failures Thereby the balance between a precise grammar and effective transformation rules already need to be considered The larger a grammar grows the more complicated it is to develop transformation rules later on The solution to this task are robust parsing techniques and island grammars Transformation In the next phase transformation rules are applied to the parse tree A direct trans formation to the target language is not possible because TestStand sequence files are stored in a proprietary binary format So the parse tree is migrated into a struc ture describing macros for TestStand sequence
67. ssage Input type ATLAS code Creates a Message Popup step that displays a popup message on run time The Input type variable indicates if the input is a text or a button input step NI_Wait Statement number Wait Number ATLAS code y Creates a wait step The Number indicates the waiting time in seconds step Statement Statement number Name Expression ATLAS code 43 4 The Translator STS Creates a Statement step The Expression variable contains the expression that has to be performed The translation of the variables in the Expression is handled by the assembler step Finish Statement number Finish ATLAS code Creates a specific statement step that terminates the test run step VTSA__NumericTest Statement number Compare Com pare Variable Compare pins Dimension Compare limits ATLAS code Creates a VTSA_Numeric_Limit Test step that compares values with one another and writes the results into the report Compare Variable contains the variable that ought to be compared The compare pins variable contains the information at what pins data is measured so that they can be displayed in the report The Dimension variable explains the dimension of the compared values zB Q oder V The Compare limits variable contains the information about the kind of comparison and the values for the comparison step SequenceCall Statement number Perform
68. t of the transformations should be done by the TXL rules Therefore the TestStnad assembler is designed to execute basic marco commands to create TestStand steps sequences and variables These commands are explained in the following 4 2 1 Concept The macro command list is being executed from top to bottom Every macro com mand has a similar structure Category Type Name Additional information ATLAS code There are four different Categories 1 Steps to create new TestStand steps 2 Sequences To create new sequences and control in which sequence steps are stored 3 Variables To Declare and initialize new variables 4 edit To Manipulates existing structures In the following each macro command of the different categories is introduced Terminal symbols are bold variable symbols italic Step This category includes every macro that is related to the creation of new TestStand steps step Label Label name ATLAS code A Label has no effect on the actual program It is used to display comments for instance step Unknown Unknown Codeleine ATLAS code An unknown statement is a special form of a lable It always has the name Unknown Codeline and different display icon To make a TestStand sequence runnable at first all Unknown statements need to be translated by hand step nop ATLAS code 42 4 The Translator STS Another special form of a label step Th
69. tarted in 1967 by the Auto matic Test Equipment Subcommitee of the Airlines Electronic Engeneering Commit tee AEEC In June 1969 ARINC published the first version of ARINC Specification 416 titled Abbreviated Test Language for Avionics Systems ATLAS Because of the increasing interest on ATLAS for potential applications in industrial and military testing the amount of applications in other areas was growing so fast so that AEEC authorised the transfer of ATLAS to IEEE IEEE Std 416 1976 ti tled IEEE ARINC Standard ATLAS Test Language was published in November 1976 The further development of the avionics system for new aircraft lead to several new versions and revisions until in March 1987 the ARINC Specification 626 titled Standard ATLAS Language for Modular Test was published ARINC Specifica tion 626 3 5 that was published in January 1995 is the most recent release and the version that is used in this work The main features of ATLAS are the Unit Under Test UUT orientation the un ambiguous communication and the test equipment independence The language is suited to define the requirements of the UUT without creating dependencies to spe cific test equipment To ensure an unambiguous description of the requirements of a test procedure for the UUT designers developers users and maintenance technicians the description of test requirements and formal structures are defined precisely Fur thermore the description of the test requ
70. that all program statements are accepted by the parser and cause no syntax error even if they are not defined in the grammar Consequently it is possible to transform common or important parts of the test description automatically while rare statement are preserved in the program for later transformation by hand TestStand is a test management software with a graphical development interface that saves the source code into binary sequence files Therefore there is no TestStand compiler that accepts text files as input That is why a TestStand Assembler program had to be developed that is capable of an automated creation of TestStand sequence files with the use of macro commands that are specially developed for this purpose The parse tree is then converted to macro commands for the TestStand Assembler using transformation rules These rules are carefully crafted to preserve the semantics of the test program To evaluate the transformation system the grammar and trans formation rules were expanded to transform 100 of an example source program Furthermore multiple additional input test programs were translated with the trans formation system to check the robustness of the parser and to record the amount of statements the grammar can transform completely The evaluation shows promising results namely that the transformation system is capable of handling the given task All tested ATLAS source programs were successful transformed to TestStand se
71. tion of the test procedure takes place It is possible to divide this structure into smaller blocks to separate test steps or test chapters from each other In the following the main procedural statements illustrated in Figure 3 4 on page 17 are briefly described Data processing statements provide the capability to save test values for further use in the test procedure perform calculations on these values and compare test val ues with specified limits Input Output statements provide the means of manually or automatically insertion or extraction of data or information during the testing process Flow control statements provide the capability to control the order of statement execution Hardware control statements describe source sensor and load functions of signals relative to the UUT Timing statements provide timing and synchronisation capabilities Databus statements provide capabilities which support the testing of UUTs that utilize buses 16 3 Test Language Transformation STS Ll tof TE IL Figure 3 4 ATLAS Procedural Structure 17 3 Test Language Transformation STS 3 1 2 TestStand The Industry Standard Test Management Software TestStand is a test management software environment developed by National Instru ments NI for execution and development of automated test sequences The software is build to handle operations like sequencing of multiple test steps calling test st
72. tyObject SetValString IncrementExpr 0 Locals Steparray 3 Locals Steparray 6 Locals NewStep AsPropertyObject Set ValBoolean CustomLoop 0 True Locals NewStep AsStep Name Trim Locals Steparray 2 Locals NewStep AsPropertyObject Comment Str Locals Steparray 7 A step generated like this could look like this BF Sameters Variables 1 Parameters Variables lt 40 Parameters Variables 1 prs 48 5 Evaluation STS 5 Evaluation This chapter presents the tests that were excuted to evaluate our test system and the results are discussed afterwards The goal of this chapter is to verify the robustness of the grammar and the properness of the transformation 5 1 Applicability To test the robustness of the parsing grammar and transformation rules the test system was used to transform a number of different ARINC 626 3 ATLAS test pro grams The results are discussed in this section The test also verifies the assumption that most parts of avionic test programs are similar to a certain point Table 5 1 illustrates various test programs that are used for testing of different parts of an air plane The table shows the total amount of code lines and the number of unknown code lines for each tested program As described in section 4 1 on page 26 every ATLAS code line that is not explicitly defined in the ATLAS grammar is identified as an unknown code line
73. ults of the runtests Because the chapters 2 x and 3 x are identical we take a closer look at chapter 1 0 to 2 9 The amount of test steps and the amount of correctly measured values is stated for every chapter Chapter Test Correct number steps measured values 1 0 2 2 2 1 25 23 2 2 148 148 2 3 14 14 2 4 9 9 2 5 101 101 2 6 70 70 2 7 91 88 2 8 51 50 2 9 37 36 Table 5 3 Runtime Value Comparisons Despite the above mentioned error no other indifferences were ascertained that could lead to the assumption of incorrect transformation Other causes for errors will be elaborated in the following section Problems In the first runthrough of the test program not a single generated chapter concurred with the reference report These Errors had different reasons 1 Programming error in the ATLAS Source program 53 5 Evaluation STS This error occured unexpectedly often e Incorrect implementation of RS232 communication e Parallel allocation of DC Voltage Sources e Interchanged Limits e Incorrect variable comparison 2 Error in the Test Unit Adapter Mostly a false values could be associated with an error in the TUA due to design issues and or faulty wiring 3 Programming or timing error with the hardware triggering Programming errors occurred while activating the relays or triggering the hard ware ressources Another problem with the hardware triggering was

Paper - STS

Contents

Download Pdf Manuals

Related Search

Related Contents