Space services: textual to formal description

Ana Maria Ambrosio1 and Eliane Martins2

1INPE - National Institute for Space Research

2UNICAMP- University of Campinas

This article presents a set of proposed steps to translate a software service specification from a textual description into a formal notation. This translation is important to reduce ambiguity inherent in textual description and avoid misunderstandings. The referred steps were initially proposed in the context of a testing methodology; however, here, a shortened version of the methodology is suggested for service description and also for implementation purposes. Two examples of packet utilization space services, the Telecommand Verification and the Large Data Transfer services, extracted from the ECSS-E-7041A standard illustrate the proposed steps. The paper discusses advantages of and limits to applying these steps.

I. Introduction The Consultative Committee for Space Data System (CCSDS) and the European Cooperation for

Space Standardization (ECSS) have been working hard on recommendations for software services for space applications. Software service consists of software functions provided by a software system. Some recommendations produced by CCSDS have become ISO standards, others have been elaborated in a space task force collaboration with the Object Management Group (OMG). In fact, space service standards have been adopted successfully by many space agencies, improving the quality of space applications. Moreover, standard software services are invaluable in reducing costs, and contributing enormously to increase international cooperation in space missions. With the use of standards, a ground station designed for a mission, located in one country, may be borrowed or rented to track satellites of another mission from another country with practically no changes. Furthermore, standardization has permitted the space industry to be more competitive in the development of software for space applications.

Space service standards describe the most common computational services to be performed by a space mission like the verification that a telecommand on board arrived correctly. Except for the CCSDS protocol specifications, these standards are generally written in textual language. Currently, the CCSDS Spacecraft Monitor & Control Working Group has adopted the use-case notation, a semi-formal UML artifact to describe the spacecraft monitoring and control services. This type pf annotation helps decrease development efforts and the time spent for each development team involved with the implementation of such services. The more precise standardized service information is provided, the better its corresponding implementation will conform.

For the space applications that require high reliability, the inherent ambiguity of textual language often lead to an incorrect interpretation and, consequently, to incorrect implementation of the service.

In order to mitigate such a lack in the current state of practice of space services description, this article presents a set of steps that guides a person to translate a service from a textual description into a formal notation. This translation is based on three UML artifacts: use-case, sequence diagram and state diagram. This set of steps was initially proposed in the context of the CoFI testing methodology1 and 2.

This article is organized as follows: section 2 presents the steps to translate textual description into a formal notation; section 3 illustrates the steps with two examples; section 4 discusses the advantages and limits; and section 5 concludes de paper.

1 Senior Technologist, Ground System Division (DSS), Av. Dos Astronautas, 1758 São Jose dos Campos -12227-010 Brazil, ana@dss.inpe.br

2 Researcher, Computing Institute of State University of Campinas (UNICAMP), Campinas, 13083-970 Brazil, eliane@ic.unicamp.br

SpaceOps 2006 Conference AIAA 2006-5680

Copyright © 2006 by the American Institute of Aeronautics and Astronautics, Inc. All rights reserved.

II. Transformation description The translation of a service from a textual description into a notational formalism is based on the use

of three UML artifacts: use-case, sequence diagram and state diagram. The first step consists of identifying the inputs, outputs, and operational variables the service should deal with. The inputs and outputs are more promptly identified, while the operational variables are not. Binder3 defined operational variable as the program’s variables for which modification causes different system responses. Here, it means a parameter for which a value variation causes service behavior changes. An operational variable may be, for instance, a counter, a packet field, a special parameter, and a timer.

The second step consists of writing the service’s functionality using the use-case notation, taking into account the inputs, outputs and operational variables. The use-case allows representing sequence of actions organized into normal and exceptional scenarios. A good description of how to recognize scenarios and organize them into use-cases is presented in the SCENT methodology4.

The third step consists of defining the entities interacting with the service. The next step uses the sequence diagram notation to represent the dynamic interaction among the entities considering the inputs, outputs, and operational variables the service deal with. The sequence diagram shows the time-dependent behavior of the service and the dependency among the entities interacting with the service. In the sequence diagram a vertical line represents an entity and horizontal arrows represent the inputs and outputs messages exchanged among the entities defined in step 3.

The last step consists of translating the sequence diagram into a state diagram. The state diagram summarizes the externally visible event (inputs and operational variables) the service may accept and the corresponding expected observable outputs the service produces in consequence. A state diagram is composed of states and transitions. A state corresponds to the interval between two inputs, and a transition comprises an input and its corresponding outputs. All inputs must be represented in a transition. Ideas of algorithms to automatically translate sequence to state diagram have been explored. Some authors such as Rumbaugh5 and more recently, Harel6 have been researching how to derive state diagram from sequence diagrams.

In short, the steps are: 1) identify the inputs, outputs, and operational variables in the text specifying the service, and

organize such information into a table; 2) write the service in use-case notation, identifying normal and exceptional scenarios of the service; 3) identify the entities communicating with the service. Consider the service as an target entity, 4) create a sequence diagram re-writing the scenarios and creating new ones as a sequence of inputs

and outputs; 5) create a state diagram representing the target entity behavior, based on the inputs of its vertical

line in sequence diagrams. Since a state diagram is a graphical representation of an automaton, one advantage of representing a

service in such a formal notation is the precision of the information, which improves the quality of the service implementation and prevents re-work. Another advantage is that the formalism also contributes to the use of automated testing tools1.

III. Steps applied to translate PUS services Space services for communication between ground and on-board application-processes are be found

in the engineering branch of the ECSS, the ECSS-E-70-41A standard7. These services are referred to as Packet Utilization Services (PUS). Some examples of these services are: Telecommand Verification, Large Data Transfer, Memory and Time Management, Event Reporting and Housekeeping and Diagnostic Data Reporting. The two first services were chosen to illustrate the application of the methodology steps, whose results are presented in the following sections.

A. Telecommand Verification service 1. A brief description

The Telecommand Verification service provides verification of the correctness of some fields in the TC packet format and feedback to the TC sender about the execution of the telecommand. The TC sender (the service client) indicates which reports about the execution stages it wants. This is done by setting one or more of the four-bits of the Ack field of the TC packet data field. These bits mean Acceptance, Start, Progress, and Completion, which correspond to the execution stage the TC is.

2. Inputs, outputs, and operational variables The inputs, outputs and operational variables related to the service are presented in Table 1. The

telecommand verification service requires information about the TC execution in order to produce the reports required by the client. Since the standard did not present such information, explicitly, here, the

inputs StartOK, PrOK, FinOK, StartNOK, PrNOK, and FinNOK are supposed to be obtained by the service.

Table 1. Telecommand Verification: inputs, outputs, operational variables. Name Description

TC packet Telecomand packet

StartOK Event indicating TC execution of start has succeeded

PrOK(p) Event indicating TC execution in step p succeeded

FinOK Event indicating TC execution of finish has succeeded

StartNOK Event indicating TC execution of start has failed

PrNOK(p) Event indicating TC execution in step p failed

Input

FinNOK Event indicating TC execution of finish has failed Output TM packet reports TM packet containing reports about the service executed

TC packet header Fields: apid and length, TC packet data field header

type, subtype and Ack field, which means: bit3 - acceptance report, .bit2 - start report, bit1 - progress report, bit0 - finish report

checksum

Operational Variables

p Current pass of the TC execution

Execution failure code Failure code related to TC execution; mission dependent value Syntax failure code Failure code related to TC packet syntax is defined in ECSS-E-

7041A - page 53

3. Use-cases Two use-cases are defined, the TC validation and the TC execution verification. An entity named TC

executor is supposed to provide the execution status of the TC. Table 2 summarizes the use-cases.

Table 2. Telecommand Verification service’s use-cases. Name: TC validation. Actor: Ground System. Description: The service receives a TC packet; check its validity and execution feasibility. It then transmits an acceptance success report if required or an acceptance report failures if an error has occurred. Input condition: TC packet arrival Output Condition: TM reports Nome: TC execution verification. Actors: ground system and TC Executor. Description: The service follows the TC execution steps and sends a success report to ground system according to both the executed step and the indication in the Ack field. In case of failure in any step, a failure report is generated and transmitted to ground system. Input condition: correct and feasible TC packet arrival Output condition: TM reports

4. Scenarios of the TC validation use-case Scenario Base (1):

1. SERVICE checks the TC packet fields are valid 2. SERVICE checks whether conditions allow the execution of arrived TC, 3. SERVICE identifies AcK.bit3 = 1, i.e., an acceptance success report is required, 4. SERVICE transmits the acceptance success report to Ground System 5. SERVICE sends TC to Executor.

Scenario 2: 3.a.1. SERVICE identifies AcK.bit3 = 0, i.e., an acceptance success report is not required, 3.a.2. SERVICE sends TC to Executor,

Scenario 3: 3.a.1. SERVICE identifies the TC is to be immediately executed, 3.a.2. SERVICE sends TC to Executor,

Nor

mal

Scenario 4: 1.a.1. SERVICE identifies illegal apid, 1.a.2. SERVICE transmits TM report indicating acceptance error with code 0 to Ground System

Scenario 5: 1.a.1. . SERVICE identifies invalid length, 1.a.2. SERVICE transmits TM report indicating acceptance error with code 1 to Ground System

Scenario 6: 1.a.1. SERVICE identifies incorrect checksum, 1.a.2. SERVICE transmits TM report indicating acceptance error with code 2 to Ground System

Scenario 7: 1.a.1. SERVICE did not recognize the service type, 1.a.2. SERVICE transmits TM report indicating acceptance error with code 3 to Ground System

Scenario 8: 1.a.1. SERVICE did not recognize the service subtype, 1.a.2. SERVICE transmits TM report indicating acceptance error with code 4 to Ground System

Scenario 9: 1.a.1. SERVICE identifies inconsistent application data (appData), 1.a.2. SERVICE transmits TM report indicating acceptance error with code 5 to Ground System.

5. Scenarios of the TC execution verification use-case Scenario Base (1): 1. SERVICE identifies Ack.bit2 = 1, i.e., a start success report is required, 2. SERVICE receives a TC start execution success indication (StartOK) from Executor, 3. SERVICE transmits a TM report indicating TC start execution has succeeded to Ground System, 4. SERVICE identifies Ack.bit1 = 1, i.e., a progress success report is required, 5. SERVICE receives a TC progress execut. success indication in step p (PrOK(p)) from Executor, 6. SERVICE transmits a TM report indicating TC step p execution succeeded to Ground System, 7. SERVICE identifies Ack.bit0 = 1, an finish success report is required, 8. SERVICE receives a TC finish execution success indication (FinOK) from Executor, 9. SERVICE transmits a TM report indicating TC finish execution has succeeded to Ground Syst.

Scenario 2: 1.a.1. SERVICE identifies Ack.bit2 = 0, i.e., an start success report is not required, 1.a.2. SERVICE returns to step 4.

Scenario 3: 5.a.1. SERVICE identifies Ack.bit1 = 0 i.e., a progress success report is not required, 5.a.2. SERVICE returns to step 7.

Scenario 4 : 8.a.1. SERVICE identifies Ack.bit0 = 0 i.e., a finish success report is not required,

Scenario 5: 2.a.1. SERVICE receives a TC start execution failure indication (StartNOK) from Executor 2.a.2. SERVICE transmits a TM report indicating TC start execution has failed to Ground System,

Scenario 6: 5.a.1. SERVICE receives a TC progress exec. failure indication in step p (PrNOK(p)) from Executor, 5.a.2. SERVICE transmits a TM report indicating TC step p execution has failure to Ground System,

Scenario 7: 8.a.1. SERVICE receives a TC finish execution success indication (FinNOK) from Executor, 8.a.2. SERVICE transmits a TM report indicating TC finish execution has failure to Ground System.

6. Entities interacting with the service Two entities interacting with the Telecommand Verification service have been identified. These

entities are represented by software systems, the Ground System, an application process in the system running in ground and the TC Executor, a peace of software, running on board.

Exc

eptio

nal

Nor

mal

E

xcep

tiona

l

7. Sequence Diagram When creating a sequence diagram, according to step 4, information about temporal order of the

occurred events is added. Both previously defined scenarios and new ones are created. Figure 1 shows the Sequence Diagram for the TC Validation use-case, whereas Figure 2 presents the Sequence Diagram for the use-case TC execution Validation.

TC(... bit3=1 ...)

Scenario 1

send (TC)

TC Executor

ServiceGround System

TM(... AccSucc rep ...)

Check fields

Check feasibity

TC(... bit3=0 ...)

send (TC)

Check fields

Check feasibity Scenario 2

TC(... tci...)

send (TC)

Check fieldsScenario 3

TC(... Apid=error...)

TM(... AccFail rep(0)...)Check fields Scenario 4

TC(... lenghtNOK...)

TM(... AccFail rep(1)...)Check fields Scenario 5

......

Figure 1. Sequence Diagram for the TC validation use-case.

TC(... Ack=1110 ...)

Scenario 1

send (TC)

TC Executor

ServiceGround System

TM(... StartSucc rep ...)StartOK

TM(... PrSucc rep(1) ...)PrOK

TM(... FinSucc rep ...)FinOK

TC(... Ack=1100 ...)

Scenario 2

send (TC)

StartOK

TM(... PrSucc rep(1) ...)

PrOK

TM(... FinSucc rep ...)FinOK

TC(... Ack=1010 ...)

Scenario 3

send (TC)

TM(... StartSucc rep ...)StartOK

PrOK

TM(... FinSucc rep ...)FinOK

TC(... Ack=0110 ...)

Scenario 4

send (TC)

TM(... StartSucc rep ...)StartOK

TM(... PrSucc rep(1) ...)PrOK

FinOK

TC(... Ack=1000 ...)

New scenarioscompleting the Ack bits combination

send (TC)

StartOK

PrOK

TM(... FinSucc rep ...)FinOK

TC(... Ack=0000 ...)send (TC)

StartOK

PrOK

FinOK

... ...

TC(... Ack=1110 ...)

Other scenarios are composed with the fault indication from the TC Executer

send (TC)

TM(... StartFail rep(f) ...)StartNOK

TM(... PrSucc rep(1) ...)PrOK

TM(... FinSucc rep ...)FinOK

......

Figure 2. Sequence Diagram for the TC execution verification use-case.

8. State Diagram The state diagram is defined by observing the line representing the SERVICE in both sequence

diagrams illustrated in Figures 1 and 2. Figure 3 illustrates the state diagram representing the Telecommand Verification service. The hachured area delimits the TC validation use-case .Assumptions were made about the transition in bold, because the standard lacked information about what to do when the fields are correct (acceptance OK) but the TC is not allowed to be executed (feasible_NOK).

Lenght_OK------------------Check type

AppData_OK------------------Check fisibility

Cksum_OK----------------Check apid

Subtype_OK---------------------Chech appdata Checking

Subtype

Checking Type

Checking Appdata

Checking

Cksum

Checking

ApidChecking Lenght

Apid_OK------------------Check lenght

TC(...)-----------------Check fields

AccOK [bit3=0] & feaseble-----------------------------------Send (TC)

AccOK [bit3=1] & feaseble-----------------------------------Send TM(AccSucc_rep)

Send(TC)

Checking Fisibility

& Reports

Inicial

AccOK [tci]-------------------

Send (TC)

Cksum_NOK-----------------------Send(TM(AccFail_rep(2))

Apid_NOK-----------------------TM(AccFail_rep)

Lenght_NOK-------------------------------Send TM(AccFail_rep)

Type_NOK-----------------------Send TM(AccFail_rep)

Subtype_NOK-------------------------------Send TM(AccFail_rep)

Appdata_NOK-------------------------------Send TM(AccFail_rep)

AccOK & feasible_NOK--------------------------------(*)

Type_OK--------------------Check subtype

TC accepted

TC execcut

ing

Start_NOK---------------------------Send TM(Start_rep)

FinOK [bit0=0]---------------------

-

FinOK [bit0=1]-------------------------------Send TM(FinSucc_rep)

StartOK [bit2=0]-----------------------------------

-

StartOK [bit2=1]-----------------------------------Send TM(StartSucc_rep)

Fin_NOK------------------------------Send TM(FinFail_rep)

FinOK [bit0=1]------------------------------Send TM(FinSucc_rep)

Pr_NOK------------------------------Send TM(PrFail_rep)

FinOK [bit0=0]-------------------------------

PrOK(p) [bit1=1]------------------------------Send TM(PrSucc_rep(p))

PrOK(p) [bit1=0]-------------------------------

Figure 3. The state diagram of the Telecommand Verification service.

3.2. Large Data Transfer service 1. Brief description:

The Large Data Transfer service (LDT) provides a common mechanism for other services to transfer large volume of data. The main function of this service is to split a Service Data Unit (SDU), containing the large volume of data, into parts and to transmit each part within a single CCSDS telecommand/telemetry source packet in a controlled manner.

2. Inputs, outputs, and operational variables

Table 3. Large Data Transfer service: inputs, outputs, and operational variables.

Name Description

Input SDU Service Data Unit received from Initiator. Output SDU Service Data Unit sent to Recipient.

TC source packet or TM source packet

CCSDS TC or TM source packet containing parts of the SDU.

Unit Type field of the SDU

Indicates whether what follows is a standard packet (0) or an extended packet (1)

Large Data Unit ID Unambiguously identify the SDU Window size Number of parts that can be downlinked prior to receiving

an acknowledgement

Operational Variables

Ack_Timer Timer trigged by the sending sub-service provider just after sending the last part of the SDU

Reception_Timer Timer trigged by the sending sub-service provider after receiving the first or intermediate part (which can be retransmitted)

3. Use-cases

Four use-cases are defined, the LDT without sliding window for downlink, LDT with sliding window for downlink, LDT without sliding window for uplinking, LDT with sliding window for uplinking. Short descriptions of these use cases are presented as follows.

Nome: LDT without sliding window - downlink. Actors: Initiator or sending service provider (an on-board entity). Description: The LDT sending on-board sub-service receives a SDU; then, checks if it is a standard or an extended packet; in the first case, splits it and transmit the parts into TM source packets as reports, assuring sequencing of the parts. The sliding window mechanism is not implemented. Input condition: SDU arrival Output condition: SDU delivered

Name: LDT with sliding window - downlink. Actor: Initiator or sending service provider (an on-board entity). Description: The LDT sending on-board sub-service receives a SDU; check if it is a standard or an extended packet; in the first case, split it and transmit the parts into TM source packets, assuring sequencing of the parts. The sending sub-service controls the parts delivering via the sliding window mechanism. Input condition: SDU arrival and sliding window option chosen. Output Condition: SDU delivered

Nome: LDT without sliding window - uplink. Actors: Initiator or sending service provider (an entity in the ground). Description: The LDT sending sub-service in the ground receives a SDU; then, checks if it is a standard or an extended packet; in the first case, splits it and transmit the parts into TC source packets, assuring sequencing of the parts. The sliding window mechanism is not implemented. Input condition: SDU arrival Output condition: SDU delivered

Name: LDT with sliding window - uplink. Actor: Initiator or sending service provider (an entity in the ground). Description: The LDT sending sub-service in the ground receives a SDU; then, checks if it is a standard or an extended packet; in the first case, splits it and transmit the parts into TC source packets, assuring sequencing of the parts. The sending sub-service controls the parts delivering via the sliding window mechanism. Input condition: SDU arrival and sliding window option chosen. Output Condition: SDU delivered 4. Scenarios of the Use case LDT without sliding window - downlink.

In scenario 2, it was supposed that the extended packets need no splitting. In scenario 3 it is supposed that the service restarts the transmission after aborting.

Scenario Base (1):

1. LDT.sending receives a standard SDU(Id) 2. If SDU is a standard packet then LDT.sending splits the SDU(Id) in equal-sized parts, 3. LDT.sending sends a First Downlink Part Report to the LDT.receiving on the ground 4. while there are parts: LDT.sending sends Intermediate Downlink Part Report to the

LDT.receiving 5. LDT.sending sends Last Downlink Part Report to the LDT.receiving 6. LDT.sending starts the Ack timer 7. LDT.sending receives Downlink Reception Ack

Scenario 2: 2.a.1. If SDU is an extended packet, then LDT.sending sends Last Downlink Part Report to the LDT.receiving on the ground 2.a.2. returns to step 6

Nor

mal

Scenario 3: 4.a.1. LDT.sending detects an error 4.a.2. LDT.sending sends Downlink Abort Report to the LDT.receiving, 4.a.3. returns to step 3.

Scenario 4: 4.b.1. LDT.sending receives Abort Downlink from the LDT.receiving on the ground 4.b.2. LDT.sending informs the Initiator on abort,

Scenario 5: 7.a.1. Ack timer timeouts 7.a.2. LDT.sending sends Downlink Abort Report to the LDT.receiving,

5. Scenarios of the Use case LDT with sliding window - downlink.

Scenario Base (1): 1. LDT.sending receives a standard SDU(Id) 2. If SDU is a standard packet, then LDT.sending splits the SDU(Id) in equal-sized parts, 3. LDT.sending sends a First Downlink Part Report to the LDT.receiving on the ground 4. LDT.sending increments by one the sequence number counter 5. while there are parts: 6. while sequence number counter < window size: LDT.sending sends Intermediate Downlink Part

Report to the LDT.receiving 7. if sequence number counter = window size: initialise sequence number counter 8. if there is only the last part: LDT.sending sends Last Downlink Part Report to the LDT.receiving 9. LDT.sending starts the Ack timer 10. LDT.sending receives Downlink Reception Ack

Scenario 2: 6.a.1. while sequence number counter < window size: LDT.sending receives Repeat Parts (Id,i) from the LDT.receiving on the ground 6.a.2. LDT.sending sends Repeated Part Report(Id,i) to the LDT.receiving on the ground 6.a.3. returns to step 6

Scenario 3: …. …..

6. Entities interacting with the service

Two entities interact with the LDT service. These entities are software systems, the Initiator, on-board, and the Recipient, on the ground. The LDT service is divided into two sub-services: LDT.sending and LDT.receiving. If the service is used for downlinking, LDT.sending is located on board and LDT.receiving is on the ground. Otherwise, if the LDT service is used for uplinking, LDT.sending is located on the ground and LDT.receiving is on board.

7. Sequence Diagram Figure 4 presents the Sequence Diagram for use case LDT without sliding window – downlink.

Exc

eptio

nal

Nor

mal

E

xcep

tiona

l

SDU(id)

Scenario 1

LDT.sendingIniciator

Split

First D. P. Report

Start Reception_Timer

LDT.receiving

Int. D. P. Report

Start Reception_Timer

Last D. P. Report

Start AcK_TimerSDU(Id)

Downlink Reception Ack

Recipient

Figure 4. Sequence Diagram for use case: LDT without sliding window – downlink.

8. State Diagram This service consists of two distinct sub-services, which present different behaviors, so Figure 3

illustrates the state diagram representing the sub-service LDT.sending behavior and Figure 4 the sub-service LDT.receiving.

Idle

Error .Send D. Abort Rep.

Sending With

Window

Sending WithoutWindow

Exist part ^ swdONSend Int. D. Part Report

swd=1

Error .Send Dwl Abort Report

swd=0Backward swd pointer

SDU . Split

Send First D. Part Report

Repeat Parts (Id, i)Repeated Part Report (Id, i)

Abort Downlink inform Initiator

Clear SDU

Exist part .Send First D. Part Report

WaintingConfirmation Swd

Exist part ^ swd = swdmaxStart Ack_Timer

Downlink Rec. Ackswd=1

Abort DownlinkInform Initiator

Clear SDU

Exist part ^ swd < swdmaxSend Int. D. P. Report

swd ++

Error .Send Dwl Abort Report

swd=0Backward swd pointer

Abort DownlinkInform Initiator

Clear SDUAck Timer Expired

Restart

Wainting Confirmation SDU

Exist part ^ swdOFF ^ swdmaxSend Int. D. Part Report

Exist part ^ Last PartSend Last D. Part Report

Start Ack_Timer

Downlink Reception Ack

Abort DownlinkInform Initiator

Clear SDU

Ack Timer ExpiredRestart

Exist part ^ Last PartSend Last D. Part Report

Start Ack_Timer

Figure 5. State Diagram for the LDT.sending sub-service.

Idle

Receving with Swd

Receving Without

Sdw

Int. D. P. Report ^ swd = swdmax Send Dwl Reception Ack

RecevingMissing Parts

with swd

Gap in the seguenceswd = 1

First D.P. ReportStart Reception_Timer

Swd=1

Recption_Timer ExpiredRestart

__Int. D. P. Report____Start Reception_Timer

swd ++

Int. D.P. Report ^ swdOFFStart Reception_Timer

RecevingMissing Parts

Downlink Abort ReportRestart

Last D.P.ReportSend SDU (Id)

Send Dwl Reception Ack

Reception_Timer ExpiredRestart

Gap in the seguenceSend Repeat Parts (Id, i)Start Reception_Timer

Repeated Part Report (Id,i)

Int. D. P. Report ^ swd < swdmax ^ swdONSend = ++

Start Reception_TimerInt. D. P. Report ^ swd < swdmaxStart Reception_Timer

Dowlink Abort ReportRestart

Reception_Timer ExpiredRestart

Reception Timer ExpiredRestart

Downlink Abort ReportRestart

Last D. P. ReportSend SDU (Id)

Send Dwl. Reception Ack

Figure 6. State Diagram for the LDT.receiving sub-service.

IV. Advantages and limits In each step, evident advantages are: (i) the definition of inputs, outputs and operational variables

help limit the scope of the service and precisely define the external interfaces; (ii) the identification of entities improve identification of the characteristics of communication medium; (iii) the use cases and scenarios establish the functionality under a user point of view; provide better understanding the functional requirement, and allow the establishment of scenarios in which the service is used; (iv) in the sequence diagram, the order of interactions and actions are established and this artifact provides a global view of the cooperation among the entities; (v) the state diagram concisely shows the dynamic handling of all (several) events graphically, using formal notation.

As a drawback one may cite that there is some overlapping of information among the notations; however, it is compensated by the different views the developer may analyze and understand the service purposes. In general, one advantage is the possibility of automation of some steps in the future. The automation may mitigate the overlapping.

Another advantage is that the steps guide a person to create separated normal and exceptional scenarios to avoid mixing the information in hard-to-read texts.

V. Conclusion The set of steps presented in this paper represent one way to translate a textual specification into a

formal description of a space service. These steps are based on UML notation so it is not difficult to be used by experts in the software business.

The methodology or technique presented by the steps presented in this paper may be applied in different contexts, such as: (i) definition of new services, (ii) understanding of a textual description of a given service for implementation purposes, (iii) preparation of the conformance tests of an implementation against its corresponding textual specification.

References 1Ambrosio, AM.; Martins,E.; Vijaykumar, N.L.; Carvalho, S.V. Systematic generation of test and fault cases for

space application validation. Data System In Aerospace, 9. (DASIA), 30 mai – 2 jun 2005, Edinburgh, Scotland. 2Ambrosio, A.M.; Martins E.; Vijaykumar N. L.; Carvalho, S.V. A Methodology for Designing Fault Injection

Experiments as an Addition to Communication Systems Conformance Testing. In: Workshop on Dependable Software - Tools and Methods, 1. (DSN), 28 jun – 1 jul 2005, Yokohama, Japan. Proceedings... Tóquio: IEEE, 2005.

3Binder, R. Testing Object-Oriented Systems-Models, Patterns and Tools – Addison-Wesley 2000. 4Ryser, J. Glinz, M. SCENT: A Method Employing Scenarios to Systematically Derive Test Cases for System

Test. Technical Report, Universität Zürich.. (2000) 5Rumbaugh,J.; Blaha,M.; Premerlani,W; Eddy,F; Lorensen,W. Object-oriented Modeling and Design. USA:

Prentice-Hall International, 500 p. (1991) 6Damm,W.; Harel, D. LSCS: breathing life into message sequence charts. Formal Methods in System Design,

n.19, p. 45-80, 2001. 7European Space Agency- ECSS-E-40-71A - Space engineering – Ground System and Operations – Telemetry

and telecommand packet utilization 30 January 2001. Noordwijk: ESA publication Division