POST CORRELATOR INTEGRATOR

SOFTWARE ANALYSIS

DOCUMENT NUMBER:

PROJECT:	RTD ERB4062PL975013

ISSUE:	DRAFT

DATE:

.	AMENDMENT RECORD

ii.	TABLE OF CONTENTS

i.	AMENDMENT RECORD	i

ii.	TABLE OF CONTENTS	ii

1	INTRODUCTION	1

1.1	Analysis Technique	1

2	Identification of processing units	2

2.1	The real-time system	2

2.2	The processor board	2

2.3	The recording board	2

1	INTRODUCTION

1.1	Object Oriented Modeling

The PCI software is developed using Object Oriented techniques. The Methodology consists of building a model of an application domain and then adding implementation details to it during the design of a system. In general this methodology has the following stages:

Analysis	Starting from a statement of the problem, a model is build of the real-world situation showing its important properties. The analysis model is a concise, precise abstraction of what the desired system must do, not how it will be done. The objects in the model should be application-domain concepts and computer implementation concepts such as data structures. A good model can be understood and criticized by application experts who are not programmers. The analysis model should not contain any implementation decisions.

System design	In the system design high-level decisions are made about the overall architecture. During system design, the target system is organized into subsystems based on both the analysis structure and the proposed architecture.

Object design	In the object design phase a design model is build base on the analysis model but containing implementation details. Details are added to the design model in accordance with the strategy established during the system design. The focus of object design is the data structure and algorithms needed to implement each class. The object classes from analysis are still meaningful, but they are augmented with computer-domain data structures and algorithms chosen to optimize important performance measures. Both the application domain objects and the computer- domain objects are described using the same object-oriented concepts and notation, although they exist on different conceptual planes.

Implementation	The object classes and relationships developed during the object design are finally translated into a particular programming language, database, or hardware implementation. Programming should be a relatively minor and mechanical part of the development cycle, because all of the hard decisions should be made during the design. The target language influences design decisions to some extent, but the design should not depend on fine details of a programming language. During implementation, it is important to follow good software engineering practice so that traceability to the design is straightforward and so that the implemented systems remains flexible and extensible.

1.2	Analysis

Analysis, the first step in the methodology, is concerned with devising a precise, concise, understandable, and correct model of the real-world.

The purpose of the object oriented analysis is to model the real-world system so that it can be understood. Therefor one must examine requirements, analyze their implications, and restate them rigorously. The successful analysis model states what must be done, without restricting how it is done, and avoids implementation decisions. The result of analysis should be understanding the problem as a preparation for design.

1.3	Problem statement

For a problem statement is referred to the design specification for the Post Correlator Integrator.

1.4	System design

System design is the high level strategy for solving the problem and building a solution. System design includes decisions about the organization of the system into subsystems, the allocation of subsystems to hardware and software components. The overall organization of a system is called the system architecture.

A subsystem is not an object nor a function but a package of classes, associations, operations, events, and constraints that are interrelated and that have a reasonably well-defined and small interface with other subsystems. A subsystem is usually identified by the services it provides. Each subsystem has a well-defined interface to the rest of the system. The interface specifies the form of all interactions and the information flow across subsystem boundaries but does not specify how the subsystem is implemented internally. Each subsystem can then be designed independently without affecting the others.

Subsystems should be defined so that most interactions are within subsystems, rather than across subsystem boundaries, in order to reduce the dependencies among the subsystems. Each subsystem may in turn be decomposed into smaller subsystems of its own. The lowest level subsystems are called modules.

1.2	Analysis Technique

This document is an analysis of the software requirements for the Post Correlator Integrator. As a tool for the software analysis a standard tool the Unified Modeling Language (UML) is used. The UML is a standard modeling language for modeling complex systems. The Unified Modeling Language fuses the concepts of Booch, OMT and OOSE. The result is a single, common and widely usable modeling language for users of these and other methods.

The UML provides different views of the 'software' system under development for better insights in different aspects of the system. The UML defines the following diagrams to provide these views.

Use case diagram	A use case is a specific way of using the system. Each use case shows a bit of the functionality carried out by the system. A use case diagram shows the relationship between actors and use cases. An actor is an external entity acting on the system. Every use case has at least one actor and every actor is connected to at least one use case.

class diagram	A class diagram shows the static information of classes, i.e. their relationships

behavior diagrams	behavior diagrams show the dynamic behavior of a system. It shows which object communicate with each other and which messages are send. It also shows the effect of that communication.

state diagram	A state diagram shows the internal behavior of an object. It shows the states of an object and how events affect those states.

activity diagram	This is an object version of a data flow diagram. Its main use is showing sequential flow control. This diagram is seldom used.

sequence diagram	The sequence diagram describes how object interact and communicate with each other. It is mainly focused on time.

It shows a single path through a Use Case, known as a scenario.

collaboration diagram	A collaboration diagram shows objects and their relationships and the interaction between those objects.

implementation diagrams

component diagram

deployment diagram

Within the correlation process (with respect to the post correlator) the following hardware components can be distinguished;

C3

D3

real-time system

correlator segment

processor board

recording board.

Besides these hardware elements there are also some external events that influence the post correlation process.

BOCF interrupt

SYSTICK interrupt

These events are VMEbus interrupts on the correlator VMEbus. These are generated by the Control board in the correlator. The PCI control board will receive the correlator BOCF and SYSTICK signal and regenerates the interrupts on the VMEbus of the PCI.

2	Identification of processing units

2.1	The real-time system

The software running on the real-time system will be mainly the same as the software running on the real-time system in the correlator. There might however be some additional configuration software required.

On of the tasks the real-time system performs is to configure and control the processing boards. The processors on the processing board will receive the same information as the correlator boards in the correlator.

On the real-time system are several tasks running.

Message server

Message processor	the message processor examines the messages one-by-one at nominally each SYSTICK interval

Application process

data server

2.2	The processor board

The processor board includes four C6x processors for processing the correlated data. These processors are interconnected using bidirectional FIFO's. Each processor has a private data bus with application memory, data memory, dual port memory and FIFO's connected to it. The private also gives access to the boards global bus.

On the boards global bus there is global SRAM, NV RAM and boot/user flash memory. The board boot from the 8 Mbs of global bus resident FLASH EEPROM. After this it will be required to load a RTOS and start the tasks running.

2.3	The recording board

The recorder boards contain two PMC modules, one C40 module and a SCSI module. The C40 board is the only board with processing power. It will directly control the SCSI controller. It does however requires information of the real-time system telling which channel to expect data from and when to start and stop a data recording. With respect to controlling the SCSI module it does have to support the sequential tape support of the SCSI protocol.

Basically the C40 has to do is find the last written position on tape. Collect data coming in through the C40 communication ports and starts writing it to tape. Until the real-time system tells him to stop.