Home

Web site plan

The latest OSA-RTS code is now managed by MOSAIC, the MOD OSA Integration Committee.

The OSA-RTS software is stored on MOSAIC GitHUB located here: https://github.com/Team-MOSAIC/OSA-RTS

If you are not already a member of the MOSAIC Group, please contact Spherea STL Support stl-support@spherea.co.uk

What is OSA-RTS

Why ATML ?

Traditional method

The use of different test systems and proprietary data formats has inhibited the exchange of useful test information.

Figure 1 - ATML – Systems CONOPS

Words describe the traditional method but picture is the modelling method words and picture need to align

After this initial development stage, the test solution will enter a support period which may span a period of up to 25 years with the prime equipment lifecycle. Within this support period a range of activities are likely to be performed including:

Figure 2 - Traditional ATS Solution

The largest spend comes during the initial TPS development. There is usually a reduction in cost when performing the support activities compared with any initial development (see figure 1). Typically, spend will be around 40-60% of the initial cost of the development for each activity across a similar timeframe e.g. for an initial TPS development taking 10 months, a TPS rewrite is still likely to take 3-5 months. Often the original development activities needed to be repeated, with little or no reuse because knowledge has been misplaced in the interim.

ATML method

Defining a family of standards for representing test information promotes the exchange among diverse test environments. In addition, these standards promote the feedback of test and maintenance information, enabling continuous improvement of both the product and its test processes.

Benefits

Figure 3 - IEEE SCC20 Standards Approach

Defining a family of standards for representing test information promotes the exchange among diverse test environments. In addition, these standards promote the feedback of test and maintenance information, enabling continuous improvement of both the product and its test processes. This is accomplished by strengthening the interfaces between activities and phases of the product life cycle, thus promoting free flow of required information. Results of experience supporting a product can be used to recommend changes in product design, which would be fed forward to the design phase for the next generation of the product (indicated by the start of a new product life cycle).

Typically, Information is sourced from design documents, such as drawings, schematics, TRDs, testability analysis describing the requirements for test for the UUTs. Test Requirements are then developed which describe the signals to be applied and measured and the sequencing of the individual tests. Using 1641, the signals may be described in various ways, such as in the Test Procedure Language (TPL) or in XML. The test sequences are described in the carrier language directly (as in VB) or in a COTS test environment, such as LabWindows/CVI. During this process a library of test signals is built up, which is specific to the project in hand (IEEE 1641 TSF libraries in figure 2). The library comprises Basic Signal Components (BSCs) and Test Signal Framework models (TSFs). This library is defined in a language neutral format. The executable Test Programs are generated from the Test Requirements, referencing the Signal Library as required.

Signals, once defined, may be re-used throughout the project in different tests and on different UUTs, thus eliminating much duplication of effort. Signals can also be reused across projects. The ATML Instrument Description standard provides a common mechanism for describing instruments in terms of the TSFs and/or BSCs that they support. When a Test Program is run on an ATS, the appropriate instrument may be selected by comparing the instrument capabilities with the signal requirements. An ATML Instrument Description will also enable an ATS implementer to verify whether a replacement instrument has the capability required by signals in the signal library. ATML Instrument Descriptions may be used by traditional instruments in terms of the TSF signals it supports, such as AC_SIGNAL, DC_SIGNAL and RAMP_SIGNAL. Modern virtual instrument components may be described in terms of their attribute capabilities, such as (for an arbitrary waveform generator) its maximum frequency, maximum point rate, maximum PRF, maximum amplitude and minimum resolution. A major advantage of using 1641 becomes apparent when Test Requirements need to be re-hosted onto a new or a different ATS.

The signal library represents the signals independently of the program language and in a language neutral format. This means that the Signal library can be ported directly from one system to another. The ease with which the Test Requirements can be ported depends on the carrier language or test environment selected for the replacement ATS. If the same carrier language or test environment is selected, then the test Requirements may well be able to be copied directly without any translation. All that is required in this situation, is to regenerate the executable Test Programs. When we use ATML as the Carrier Language, the same package can just be re-deployed onto the new target platform