Jean-Yves Berenger

Francine Jeremie

Christian Bichet

NETWORK FOR MULTIMEDIA APPLICATION

Keywords: MOST, IDB1394, DVD player, digital TV, streaming

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

We have been used for a long time with electronic entertainment and communications in our homes and offices: digital TV receiver, camera, DVD Player, Personal Computer, Game console, MP3 player… But we now expect our infotainment devices to be available any time and anywhere. And, of course, we should have them in our cars too.

The challenge for the car manufacturers is to integrate these consumer electronic digital devices at a cost compatible with the automotive market constraints and with a minimum impact on the cable harnesses.

One way to solve issues is to network those devices together through a robust and reliable high-speed serial bus to replace the classical analogue link. This high-speed bus shall establish a direct link between electronic consumer's world and the automotive world; it shall offer high data rates to support numerous channels video and audio stream. It shall be easily adaptable to any upcoming consumer's digital devices, and must be easy to set up.

Today, two high-speed serial buses can be used for those applications:

• MOST (Media Oriented Systems Transport) • IDB-1394b ( IEEE-1394 or FireWire especially adapted for automotive applications)

The MOST network is already well known by European carmakers, we will limit our paper on an overview of MOST to focus us on the IDB-1394 less known in automotive area.

Overview of MOST

The MOST is a multimedia fiber-optic network designed for automotive application. BMW, DaimlerChrysler, Harman/Becker and Oasis Silicon Systems founded the MOST Cooperation in 1998 to standardize the MOST technology. MOST network is an extension of D2B network and was developed specifically for interconnecting automotive multimedia devices and enable distributing audio, voice, and data in a digital way (targeted devices are navigation unit, phone, active speakers, CD audio player, microphone,..). The first automotive application started in 2001. The wake up function in general is derived from sensing activity on the RX line. A receiver device should be able to detect activity and wake up the target device.

MOST and the OSI model

• Layers 3 to 6 are processed by Netservices software on a microprocessor. • Layer 2 is realized by a specific OASIS component.

• Layer 1 is realized by a FOT.

MOST Protocol

The MOST protocol allows two types of transmission mode:

• Synchronous mode

MOST future evolutions

The MOST Cooperation is working on new specification to increase the data rate up to 150 Mbps. This new specification will define a new physical layer introducing new technologies in vehicle. The coding scheme will change to support higher data rate and VCSEL transmitter will replace LED transmitter. Thus, optical wavelength will change from 650 nm visible to 850 nm infrared and Plastic Optical Fiber couldn't be used any more. It will be replaced with PCS (Plastic Clad Silicon) fiber. Backward compatibility with the 25 Mbit/s version and validation of the new physical layer is the next MOST challenge.

IDB-1394

Introduction

The

IDB 1394 model

The typical hardware topology consists of a physical layer (PHY) and a Link Layer controller (LLC). PHY and LLC is often integrated into the same chipset

The PHY layer has physical signaling circuits and logic that are responsible for power-up initialization, arbitration, bus-reset sensing, and data signaling. It can have one to sixteen ports and incoming data signal is automatically repeated to every port. A PHY acts as a repeater. The IEEE 1394 standard also defines two software layers, a transaction layer and a serial bus management layer, often implemented in firmware and named 1394 stack.

The bus management layer refers to setting up the node on the bus and keeping track of the capabilities and addresses of other nodes on the bus. It can contain all or some of the following functionalities:

• Isochronous manager : keeps the budget of bandwidth and isochronous channel • Cycle Master: ensures node synchronization • Bus manager : builds speed and topology maps The transaction layer provides protocol for asynchronous transfers and can perform bus configuration and management. Application layer is what ever we want the device to accomplish and contains the protocol used to communicate with other device and potentially the user interface. Based on this model, three kind of link layer chipset exist today on the market: 1.

General purpose link controller which has no protocol layers integrated and need an external microcontroller 2.

Processor link layer controller which integrates a small microprocessor, some RAM, and the necessary protocol layer(s); This link layer can have standard interface, like I2S, I2C, SPDIF, BT 656, etc… and doesn't need any external microcontroller

IDB 1394 Topology

The physical topology for a typical IDB 1394 network is a tree structure. Typically, a node will have a least two ports which enables multiple nodes to be daisy chained together. If a node has more than two ports, multiple branches can be created. During initialization, one node is defined to be the root node with all nodes extending down different branches. The topology can have any number of branches. A root node is re-elected after each bus reset (bus reset is the consequence of device connection/disconnection, device resuming from sleep mode to active mode or network initialization). Root node shall contain cycle master and bus manager. In the automotive implementation it is required to force one specific node to be the root node in order to control the network management.

IDB 1394 Physical layer

IDB 1394 physical layer consists of two optical fibers. The transmission is full duplex and optical links are unidirectional. The 8B/10B coding scheme used allows transporting clock and data in the same bit stream. Transmitter periodically inserts K28.5 symbol in data to allow receiver synchronization. When neither node is sending data, they always continue to exchange periodic K28.5 symbol to keep the synchronization. With LED transmitter, the power budget is around 14.5 dB.

POWER MODE IDB 1394 PHY component implements three power consumption modes

• Full power : all port are powered and active

• Sleep : all ports are in sleep state and able to be awaken by network activity (port is still listening for tone) • Ultra low power; all ports are disabled, only event from internal microcontroller can awake the PHY FIBER OPTIC TRANSCEIVER IEEE TA2004024 PMD for wake up on LAN document defines FOT dimensions and electricaloptical characteristics for S100, S200 and S400 bit rate in order to guarantee all connectors and FOT' s interoperability.

CONNECTOR

IDB 1394 specification defines the interface and latch of an optical connector for the embedded network. This connector is adapted from the consumer PN07 connector and the FOT is directly integrated into the header (without pigtail). Three coding are specified to avoid incorrect mating. Plug designs for fixed ferule and loose ferule are provided IDB 1394 defines the copper connector used to interconnect portable devices to the automotive embedded network. The CCP socket inter mate with both IEEE 1394b-2002 bilingual type 2 and type 3. This connector can provide power to the connected node. The connector is already standardized with multiple manufacturers. The design was optimized for EMI/RFI protection.

CCP IDB-1394B CONNECTOR

Plug with loose ferule

Header with FOT

CLOCK SYTEM

Each Physical Layer's node requires a 49.152 MHz system clock, which can be derived from either an external crystal oscillator or an external clock. The clock drives an internal phase-locked loop (PLL), which generates the required reference signal. This reference signal provides the clock signals that control transmission of the outbound encoded information. A 98.304 MHz clock signal is supplied by the PHY to the associated LLC for synchronization of the two devices when operating the PHY-link interface in compliance with the IEEE 1394b-2002 standard.

IDB 1394 and the OSI model

IDB 1394 protocol

The 1394 protocol supports both asynchronous and isochronous data transfers. Isochronous transfers are always broadcast in a one to one or one to many fashion. There is no error correction or retransmission available for isochronous transfers. The maximum amount of bandwidth an isochronous device can obtain is only limited by the other isochronous devices that have already obtained bandwidth from the isochronous resource manager. Asynchronous transfers are acknowledged and responded to. This allows error checking and retransmission mechanisms to take place.

CONTROL COMMAND Control commands are defined in specific AV/C subunit specification document (i.e. AV/C sub-unit CD changer, AV/C sub-unit disc,…) An AV/C command frame can be up to 512 payload bytes. Maximum effective bit rate on the control channel is 93 Mbit/s @S100.

ISOCHRONOUS TRANSACTIONS Isochronous channel guarantee bandwidth to applications like real time audio, video and voice. When an application is allocated an isochronous channel, it is guaranteed to send isochronous packets at regular intervals. The cycle master (in the root) broadcasts every 125 µs an isochronous «cycle start». Once all nodes have received this message, an isochronous communication window opens. All nodes waiting with pending isochronous messages will then send. Once all isochronous messages have been transferred using a maximum of 100 µs (80% of the bandwidth), the isochronous communication closes, and asynchronous communication are allowed to take place, until the next 125 µs cycle begins.

Isochronous communication uses a channel scheme where nodes transmit over a numbered channel and receive by listening on the receiver channel. Talker needs to allocate the necessary bandwidth and a channel number at the isochronous resource manager (IRM) before sending data. Isochronous transactions are packed based and the overhead consists of 4 bytes of header and 8 bytes of checksum for data and header. DATA can be up to 4800 bytes at S400. The

AMI/C

The Automotive Multimedia Interface Collaboration (AMI-C) is a non-profit corporation comprised of motor vehicle manufacturers from around the world as members. It was established to facilitate the development, promotion and standardization of automotive information and entertainment system interfaces to motor vehicle communication networks. AMI-C produces a set AMI-C Technical Documents (requirement, specification and reference documents) concerning automotive information and entertainment. For example, AMI-C defines the Vehicle Interface Protocol for 1394. This specification describes the protocol and messages to control and manage vehicle information over 1394 networks.

  Principal characteristics:• Data rates up to 24.8 Mbps • Optimized for use Plastic Optical Fiber (POF) • Full support for real-time audio and MPEG 1 compressed video • Asynchronous and synchronous data transfer • Constant Bit Rate (CBR) data support • Up to 64 devices • Simultaneous transmission of multiple data streams such as control, packet and real-time information • Low overhead due to embedded network management 2.1 Physical layer Three topologies are possible with MOST: • Ring • Star • Peer to Peer The specified physical layer requires a Fiber Optical Transceiver (FOT); each node is connected in transmission and in reception to one multi-mode fiber-optic. The signal is coded in Manchester encoded and sent in a continue stream. A bypass system allows to keep the continuity of the network if a node becomes inactive. With use of LED transmitter, power budget is around 14 dB. Fiber Optical Transceiver form factor is not part of the standardization and the physical interface consists of the following signal lines: • RX -receive data line • TX -transmit data line Optional lines could be: • Power • Ground • Wake_up -an optional wake up line for waking up the MOST network

  Ultra low (if optical activity is detected RX transmits a wake signal that can be used to wake up the node's microcontroller) 20 µA (max)

  Physical, data and network layers are standardized in IEEE 1394a and 1394b specification Session layers and presentation layers used to communicate are standardized by IEC and IEEE organization to ensure devices interoperability. Some examples: • IEC 61883-2 to 8 protocols handle isochronous streaming data like video and audio (compressed video : DV, MPEG2 TS, compressed and uncompressed audio) • IEC 61883-1 protocol is utilized to send command and control between nodes on the network. • ANSI SBP-2/3 protocols are currently defined to send/receive asynchronous data blocks between nodes on the network (hard disk, DVD-ROM player,…). • IEEE TA1999023 IIDC protocol handles uncompressed video data for camera. • "IP over 1394" standardizes how to transfer IP packets across a FireWire interface.

3. 7

 7 IDB 1394 future evolutions IDB forum and 1394-trade association are working on new specification extension to use UTP, STP and wireless over Ultra Wide Band in automotive.

Peer to Peer Hub Star Ring

  of protocol overhead; and buffering with a MOST network frame rate at 44.1 Khz. This system is very cost efficiency. If all the network bandwidth is dedicated to synchronous mode (no packet data transfer), this transmission mode allows to support up to 15 uncompressed CDquality audio channels (16 bit stereo at 44.1 kHz). However, several sources using different sampling frequencies and mode to output data can be connected over the network, (i.e. DVD audio supports six channels of 24 bits uncompressed audio data at a 48 kHz-sample rate, DVD video signals use compressed with Variable Bit Rate (VBR) at 48 KHz, Digital Video Broadcast use compressed with CBR and 188 bytes packet long at 48 Khz,…), these sources shall be adapted to the MOST network characteristics; transcoding native variable bit rate stream into constant bit rate stream, re-synchronizing data to the clock of the MOST network, segmenting 188 bytes long packet., etc…all in real time. Theses operations consumes CPU and buffers decreasing the system cost efficiency.

	At network initialization, the timing master node shall
	fix the boundary between time for synchronous data
	transfer and time for packet data transfer. If
	synchronous data transfer is expected to use
	maximum of the bandwidth (60 bytes), packet data
	transfer will not be possible. Following table shows
	some bit rate combination @ 44.1 KHz frame rate.
					Synchronous	Packet data
					data
	Theoretical bit	rate	(without	protocol)	8.5 Mbit/s. 10.5 Mbit/s 21 Mbit/s	14.4 Mbit/s 10.5 Mbit/s 0	7	Application
							6	Presentation	Function Blocks
	Packet data transfer can be used for high frequency	5	Session	Most Netservices Layer II	Microprocessor
	burst type application such hard discs transfer, picture or graphic data transfer. Access to this type	4	Transport	Most Netservices layer I
	of data is provided in a token ring manner however	3	Network
	low level retry and acknowledgement mechanism
	are not implemented, user has to implement its own	2	Link	OASIS chipset
	high level protocol following application targeted.
	Control data is used for commands, status and	1	Physical	FOT
	diagnosis messages between the single nodes of the
	bus. Protocol on this channel runs in a Carrier Sense
	Multiple Access (CSMA) manner; low-level retry and
	acknowledgement are implemented. A control
	message has a max of 18 bytes payload and the net
	data rate on this channel is 105 Kbit/s @ 44.1 KHz
	frame rate. Synchronous mode is used for CBR data transfer. Accessing this channel is provided by time division multiplexing (TDM) and allocation of a maximum of	• Asynchronous mode • Control data • Packet data
	height bytes at each allocation request. A connection master node administers the synchronous resources and all requests for allocating or establishing connections must be directed to it before any transactions.	The master node periodically generates a frame shared between time for asynchronous data transfer and time for synchronous data transfer. The frame rate can be fixed at 38 KHz, 44.1 KHz or 48 KHz. Slave nodes can periodically put data or extract data
							in/from the frame.

If sources and receivers sampling frequencies are identical to the network frame rate there is no need for additional buffering to put and extract data over the network. I.e.: a CD audio player and a stereo active speaker run both at 44.1 Khz sampling frequency, they can communicate through the network without need

  Multiple independent video sinks • Multiple independent audio sinks • Sinks may be fed simultaneously independently from the video-audio sources.The network must transport audio-video data in real time. IDB-1394 isochronous transport provides a guaranteed rate of speed that is constant for timecritical devices and applications. This is very suitable for such applications. Uncompressed video data transports are defined in order to keep the price of

	31 automotive display as low as possible (no de-0	A complete 192 bytes (188 bytes + 4 bytes
	data_length decompression, no video scaler). tag channel	tcode	sy	timestamps) of source packet is split into 8 data blocks with a length of 24 bytes each. An
		header_CRC			isochronous packet, with 8 bytes CIP header, containing zero, one, two or four data blocks or an
					integer number of source packet is sent over the
		DATA			network every isochronous cycle. The display buffers all the 8 data blocks of one
					source packet and thanks to the CIP header
		data_CRC			information combine them in order to reconstruct the
					original transport packet before sending it to the
					decoder. According to the IEC 61883-4 specification,
	12 bytes overhead allow to be able to transmit either variable bit rate data or constant bit rate and give some information the receiver may need to	the display buffer size is around 4 Kbytes A complete transport packet can be transferred in one isochronous cycle
	decode the incoming data (sy field may indicate the
	start of a data block when transmitting	Audio-Video streaming
	uncompressed data, tag field indicates that CIP-
	based data is contained in the isochronous	Audio-video devices can present audio and visual
	payload,…).				information to inform the driver and to entertain the
					passengers. The vehicle system architecture related
					to audio and video devices is characterized by three
	The packet based isochronous transactions allow Data (payload) SYT (16 bytes) CIP FDF header (8bytes) DATA	key points: 1394b network • DVD player	OEM BUS
	transporting all kind of real time audio-video data;
	constant bit rate, variable bit rate, compressed, and	Display 1
	uncompressed, without forcing the sources to be adapted to the network characteristics.	Game console
	One video example:				Display 2	1394 automotive
	The DVB-T tuner sends the MPEG TS over IDB	network
	1394 through IEC 61993-4 protocol.			DVD player	CCP
	This protocol allows to timestamp each incoming
	packet of 188 bytes. The display will use these
	timestamps to recreate the original stream. Thus the	Navigation
	bit rate stream can be transported without induced	MP3 player
	jitter and the protocol ensures flicker free video at	others
	the receiver.				Portable devices	Embedded devices
	Timestamps	Transport packet
	(4 bytes)	(188 bytes)
	Source packet (192 bytes )

Conclusion

Most is well implanted in vehicles today but could be limited. On the other hand, IDB-1394, even if it is a new network in the automobile field could take advantage from already existing products coming from consumer world. It enables a cost-effective introduction of consumers electronics devices (such as CD players, DVDs, Digital TV receiver,..) in vehicles. Due to the work done by organizations like IDB, AMI-C… and including now automotive requirements IDB-1394 is completely ready, including automotive requirements to be used as an automotive highspeed bus multimedia backbone. Products as navigation are already available by Toyota and some global projects like rear seat entertainment with IDB-1394 as multimedia backbone are on the way and will equip vehicles in 2009 in vehicles.


Yves Samson

Computerized System Validation: Regulatory Compliance and Process Safety in the Pharmaceutical Industry

Keywords: computerized system validation, regulatory compliance, system life cycle, risk management, testing, GAMP ®

One of the major concerns of the pharmaceutical industry is the importance of the regulations which have to be fulfilled. These establish various requirements for processes and associated systems without defining the ways to achieve the expected compliance. Such regulatory requirements concern also computerized systems used for manufacturing-, laboratory-, distribution-or clinical study-related activities. After a short introduction to the pharmaceutical regulatory framework, this article will show the approach for achieving the regulatory compliance used within the industry, based on the recommendations promoted by the GAMP ® Guide. Thereby, three key-topics will be presented: system life cycle, risk management and system testing.

Introduction: "You'll soon feel better! …"

When we were sick as children, after being given some medicine, we often heard the sentence "You'll soon feel better! …". Indeed, in highly developed countries, medicinal products extend the life of humans by 16 years on average. At the same time, due to side effects, medicinal products reduce the life of humans by 37 minutes on average. [START_REF] Dr | Global GMP regulatory conference[END_REF] Unfortunately, in some third world countries, 10 to 50% of all drugs which patients receive are counterfeits. This signifies that some of them are without any active ingredients and/or with harmful other ingredients. [START_REF] Dr | Global GMP regulatory conference[END_REF] The control of the market, with the help of regulations, inspections and testing in medicine control laboratories, makes the difference. The control of the market is as effective as it is focused on the risks associated with the products for the patients. The challenge for the pharmaceutical industry is to fulfil regulatory requirements and at the same time maintain an economic efficiency.

Pharmaceutical Regulations

Regulatory Agencies

A regulatory agency is a national governmental authority which is responsible for the control of healthcare organizations regarding the correct consideration of national and, if appropriate, international standards. The goal is to protect the citizen, i.e. the patient's health. Historically, the US Food and Drug Administration (US FDA) was the first to initiate the definition of the principles for software validation. Today, the major Agencies (incl. EMEA through the European Commission) establish such principles and related rules directly or via harmonisation working groups such as PIC/S.

Regulatory inspections

Regulatory agencies perform inspections of pharmaceutical organizations and their facilities on a regular basis. The inspection objectives are to control workflows, processes and systems in relation with a product. For this reason, computerized systems are inspected based on their impact on the product quality and safety. In this way the inspection focus on computerized system could be more or less strong. Since regulations define only requirements which have to be fulfilled by the pharmaceutical organizations without defining the ways to achieve the expected compliance, there is no absolute compliance standard.

Principles

The complex regulatory framework impacting pharmaceutical processes and equipment could be summarized in the following definition established by the US FDA in 1987: "Process validation is establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes." [START_REF]General Principles of Process Validation[END_REF] As consequence of this first definition, software validation is considered to be "confirmation by examination and provision of objective evidence that computer system specifications conform to user needs and intended uses, and that all requirements can be consistently fulfilled." [START_REF]Glossary of Computerized System and Software Development Terminology[END_REF]

Regulatory impact on computerized systems

The consequence of the above mentioned principles is that every system involved in product-related processes must be validated.

Various computerized systems are impacted by these requirements. There are for example: Laboratory equipment used for:

• Product development The challenge for the pharmaceutical organizations consists of achieving a consistent level of compliance based on the above mentioned principles for every impacted system.

Computerized System Validation

Validation in the daily business

"Process validation is establishing documented evidence which provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes." [START_REF]General Principles of Process Validation[END_REF] This principle can be illustrated based on the following scheme:

• Module & integration tests • Installation qualification (IQ)
• Operational qualification (OQ)

• Performance qualification (PQ)

• Factory and site acceptance tests (FAT, SAT) Traceability matrix. The main objective of the validation is to provide evidence that requirements are fulfilled and that the system (or the process) is fit for purpose.

How to fulfil regulatory requirements?

Complying with regulations implies satisfying, among others, requirements such as:

To Although computerized system validation (CSV) impacts computer systems as well as users, procedural controls and the environment, the following part of this document will discuss only the aspects of: System life cycle Risk management System testing.

System Life Cycle

In order to work in a consistent manner, a well structured and formalized system life cycle (SLC) is necessary.

Often, the SLC is reduced by covering only the development activities: "System Development Life Cycle" (SDLC). Although the development phase is very important regarding system quality as well as security and safety, regulatory compliance requires that a system should be developed and operated according to current good practice.

System Development Life Cycle

Regulations as well as industry standards do not prescribe any life cycle model. Nevertheless, the usual reference model is the "V Model" (see Figure 1). One of the major benefits of this representation is to highlight the strong relationship between "technical specifications" (left branch) and the corresponding "test specifications" (right branch). Because regulations request evidence that the system meets the requirements, it is essential for performing validation activities that tests are systematically defined as well as that every requirement is tested in an appropriate manner. Depending on the system complexity, the life cycle could be adapted and customized 1 .

1 Usually, the life cycle is binding and is defined in the system specific Validation Plan (or Qualification Plan).

The SDLC of a specifically developed system should describe every activity with an appropriate granularity and depth. In this case, the design specifications should describe software design as well as each software module. By so called "Commercial Off-The-Shelf" systems (COTS), the SDLC includes little actual (software) implementation activities which are under the system owner's direct responsibility. Regardless of the chosen approach, it is the responsibility of the system owner to ensure that development activities are performed according to the current good practice. For COTS systems as well as for sub-contracted development work, supplier audits are an efficient way for demonstrating supplier maturity. In case of deficiencies, corrective (and supporting) measures based on the observed weaknesses should be put in place and controlled during the project. Even if the V Model is widely used as the reference model for the development activities it does not assume that a sequential waterfall model has to be followed. An iterative approach of the development tasks is also acceptable. In such cases, each iteration should follow the V Model (specify, implement, test, report) and the entire development corresponds to a succession of several "Vs". It is worth mentioning here that the approach recommended by the (IBM Rational) Unified Process satisfies both the requirements for a well formalized prospective workflow as well as an iterative methodology facilitating good progress control and risk management based on prototyping.

Integral System Life Cycle

At the end of the development, as soon as the system becomes operational and until its retirement, it is necessary to take into account the corresponding regulatory requirements. For this reason, a binding formalization of activities is indispensable. It concerns the following topics:

System access control • Physical and logical access control Data management [START_REF] Samson | White Paper: Introduction to Good Process Record Management (GxP)[END_REF] • Backup and restore

• Archiving and retrieval

Disaster recovery and business continuity Change control and maintenance. At the time the system must be retired, it is also necessary to decommission the system with sufficient control:

To prove that the system worked correctly until the end To ensure the integrity of records which must be kept at least for regulatory purpose after the system is turned off. This Integral System Life Cycle is also called the "Spoon Model" due to its representation which is similar to a spoon (see Figure 2).

URS User Requirements Specification

FS

Life Cycle Requirements

Regardless of the kind of specific life cycle activity, the following requirements must be fulfilled:

The activity must be achieved prospectively • Pre-defined operational procedures (SOP)

• Pre-defined task schedule, if appropriate

• Pre-defined controls and acceptance criteria

• Pre-defined of behaviour in case of deviation Activity as well as documentation must stay under change control based on formalized procedures Procedures (SOP) must be exercised (especially SOPs which are rarely used, e.g. disaster recovery). Because process documentation is vital to demonstrate that the process and systems run accordingly to the specifications, data and especially record management are critical tasks. One objective of the CSV is to ensure the integrity of data and records. (See also [START_REF]European Commission: Annex 11 "Computerized Systems" to the EU Guidelines of Good Manufacturing Practice for Medicinal Products[END_REF], [START_REF]Electronic Records; Electronic Signatures[END_REF], [START_REF] Fda | Guidance for Industry, Part 11, Electronic Records[END_REF] and further [START_REF] Pic/S | Good Practices for computerized systems in regulated[END_REF]) In addition to the regulatory agencies, which perform inspection to control healthcare organizations, controls, releases and audits are executed internally by the quality assurance (QA) department. Every SOP, every URS, every validation plan and report as well as every change request must be approved by QA.

Risk management

Since it is not possible and not cost-effective to test all functionality (and especially in combination with each other), it is necessary to follow a more pragmatic approach based on the identification of critical functions and process steps. The validation (incl. test) effort will be focused on the functionality identified as critical.

Which risks?

The criticality and finally the risk assessment should consider the following aspects and impacts:

Safety and security • Risk for people (safety)

• Environmental risk (ecology)

• Risk for plant and equipment (security)

Product related risks • Insufficient quality: the product does not meet the pre-defined quality attributes Regulatory risks • Regulatory and/or legal requirements are not fulfilled correctly Operational and business risk • Corporate reliability and reputation, ...

Risk assessment

Even regulatory agencies have endorsed a validation approach based on risk evaluation for a number of year, they do not prescribe or recommend any particular methodology regarding risk assessment and risk management. For this reason, the GAMP ® Forum proposed in [START_REF]GAMP 4: Validation of automated systems[END_REF] a basic approach which can be easily enhanced with the help of more intensive methods like HAZOPS, HACCP, FMEA, or based on ISO/EN 14971:2002. After identification of the risk scenarios, the risk evaluation must consider for each scenario the following aspects (see also [START_REF]GAMP 4: Validation of automated systems[END_REF], Appendix M3):

Risk likelihood Business impact Probability of failure detection The business impact should be understood widely (covering safety, security, product quality and operational aspects incl. regulatory compliance). Based on the assessed criticality, risk mitigation measures should be defined, implemented and tested. Depending on the criticality, good engineering practices and, if needed, more intensive qualification work should be specified in order to ensure that the mitigation measures are correctly implemented, without producing additional (and unassessed) risks. (See also [START_REF] Samson | Risiko-orientiert Reinräume zeitund kosteneffizient qualifizieren und validieren[END_REF]) Finally, whatever the chosen risk evaluation method is, the risk management process must be formalized and the results have to be documented accurately. To provide evidence that a system is fit for purpose, meeting user and business requirements. For this reason, every specification item, identified as critical regarding the validation state, needs to be tested formerly. During the initial acceptance tests, the system design fitness should be demonstrated. During the qualification, the IQ should prove the correct installation of the system. Afterwards, OQ and PQ should demonstrate the fitness for purpose of the system. The PQ should support the final user acceptance of the system. For automated testing, a different formalism could be agreed). The test results must be consistently reproducible and the test records must be reviewed and approved. The basic principle is that tests must be performed and test records must be approved prior to the beginning of the next test phase unless a different procedure is agreed in the validation plan. Although the required test formalism could seem to be a little heavy, the regulations expect such formalism. Test consistency and reproducibility are the keys for providing "objective evidence that computer system specifications conform to user needs and intended uses, and that all requirements can be consistently fulfilled." [START_REF]Glossary of Computerized System and Software Development Terminology[END_REF]

Yves Samson, Kereon AG, Basel Computerized System Validation

Industry Standards

Because regulations do not give any recommendation about the way to achieve compliance, regulated users2 need support regarding the possible and appropriate ways to achieve regulatory compliance and to maintain the computerized systems in a validated state. Already in the second half of the eighties, the pharmaceutical companies started to work together within the PMA CSVC on the elaboration of a guideline related to the Computer System Validation. At the beginning of the nineties, after several difficult inspections (so called "pivotal inspections"), several people, mostly coming from the industry, started the "GAMP ® initiative", initially to provide guidance for the suppliers of the pharmaceutical industry. After several years and versions, the GAMP ® Guide ( [START_REF]GAMP 4: Validation of automated systems[END_REF]) is a recognized document within the healthcare sector for users, suppliers as well as regulators. The Guide is not binding and it is neither a regulation nor a norm. However the recommendations proposed by the GAMP ® Forum represent a reasonable and well accepted way to meet regulatory requirements, even if other approaches are possible. Today, several "Good Practice Guides" develop specifically the concepts promoted in GAMP 4 ( [START_REF]GAMP 4: Validation of automated systems[END_REF]) needing a particular focus, e.g.:

Validation of Process Control Systems Validation of Laboratory Computerized Systems IT Infrastructure Control and Compliance Electronic Records and Signatures. The GAMP ® Forum is now a technical subcommittee of ISPE. On the regulator's side, international working groups have developed guidance for the inspectors. The guide PI 011-2 [START_REF] Pic/S | Good Practices for computerized systems in regulated[END_REF] edited by PIC/S is one of the major documents concerning computerized systems validation.

Conclusion

Compared to the situation 15 years ago, industry and regulators now have available valuable and mature guides and recommendations for achieving regulatory compliance. Although the formalism regarding processes and the documentation of activities is strong, the pharmaceutical industry has wide freedom to define the most appropriate approach to achieve compliance. Based on a few fundamental concepts and on a prospective approach to project management and engineering activities, the regulated user is able to choose the way how to fulfil regulatory requirements for its particular system. This is only possible if the life cycle for the development and operational phases are correctly formalized -based on an established quality management system -and if the existing risks are assessed consistently. Finally, nothing is possible without the presence of a QA organization which controls the application of the defined working approach and its conformity (compliance) with the organization QMS and applicable regulatory requirements

Acknowledgement

The author acknowledges especially Philip A. Burgess for the review of this paper and the members of the GAMP steering committee as well as various speakers at ISPE conferences, in particular:

Chris Clark Anthony J. Margetts David W. Selby Guy A.S. Wingate Siôn Wyn.

Glossary

Figure 1 :

 1 Figure 1: Reference "V Model"

  Figure 2: Spoon Model

  The first and major objective of testing is:

3. 5 . 2

 52 When to test? According to the reference life cycle model, several test phases, achieving different goals, should be executed: Acceptance tests • Software module tests & software module integration tests • Factory acceptance tests (FAT) • Site acceptance tests (SAT) Qualification • Installation qualification (IQ) • Operational qualification (OQ) • Performance qualification (PQ).

'users' (owners of the good practice computerised systems being inspected) are collectively referred to as 'regulated users'[START_REF] Pic/S | Good Practices for computerized systems in regulated[END_REF]

Computerized System Validation


O Akerlund

P Bieber

E Boede

M Bozzano

M Bretschneider

C Castel

A Cavallo

M Cifaldi

J Gauthier

A Griffault

O Lisagor

A Lüdtke

S Metge

C Papadopoulos

T Peikenkamp

L Sagaspe

C Seguin

H Trivedi

L Valacca

ISAAC, a framework for integrated safety analysis of functional, geometrical and human aspects

Keywords: system safety assessment, certification, formal methods

This paper aims at presenting methods and tools that are developed in the ISAAC project (Improvement of Safety Activities on Aeronautical Complex Systems, www.isaac-fp6.org), a European Community funded project, to support the safety assessment of complex embedded systems. The ISAAC methodology proposes to base as much of the safety analyses as is feasibly possible on simulable and formally verifiable system models that include fault models and can be shared both by safety and design engineers. On one hand, tools were developed to support safety assessment of Simulink, SCADE, Statemate, NuSMV and AltaRica models. On the other hand, formal models are coupled with additional models to address the problems of common cause analysis and human error analysis.

Introduction

This paper aims at presenting methods and tools that are developed in the ISAAC project (Improvement of Safety Activities on Aeronautical Complex Systems), a European Community funded project, to support the safety assessment of complex embedded systems.

Typical avionic systems studied in ISAAC are heterogeneous systems made up of computer-based controllers (e.g., real-time controllers) and mechanical components. Moreover, for safety and operational reasons, these systems are often reconfigurable, thus making it difficult to master the numerous combinations of cases and the system dynamics during the safety analysis activity. ISAAC aims at improving the classical safety analysis means, such as fault tree analysis, which are devised to cope with the system structure without taking into account the system dynamics. Furthermore, ISAAC wants to improve the sharing of information, which is specific to safety engineers, with system designers. These objectives have been partly tackled by a previous European project called ESACS (Enhanced Safety Assessment for Complex Systems, 2001Systems, -2003)). The ESACS project proposed to base the safety analysis on dynamic formal system models that include fault models and the ESACS teams used more specifically the following formal languages for modelling reactive systems: Simulink, SCADE, Statemate, NuSMV and AltaRica [START_REF] Bozzano | ESACS: an integrated methodology for design and safety analysis of complex systems[END_REF]. Safety assessment tools were developed based on existing proof engines. On the one hand, these tools enable to search for sequences of events that lead to failure conditions of interest. On the other hand, they enabled the assessment of qualitative safety requirements such as no single failure shall lead to a critical failure condition. The ESACS methodology and tools were applied to several case studies provided by the aircraft manufacturers.

On the basis of these promising first results, the ISAAC project aims at generalizing the use of numerical simulable models to support a more comprehensive set of safety analyses. On the one hand, new tools are being developed to extend the use of formal models on their own. In particular, they support safety requirement allocation, failure mode and effect analysis, testability analysis and mission reliability analysis. On the other hand, formal models are coupled with additional models to address the problems of common cause analysis and human error analysis. In the case of common cause analysis, common cause failures, due to the geometrical layout, are found through the use o f 3D models (e.g., CATIA models) and are injected into the formal model that specifies the functional behaviour of the system. Similarly, in the case of human error analysis, plausible pilot errors are investigated by coupling flight simulators and models of pilot mental states and operation procedures. Then, the emerging pilot errors are injected in the formal model to take into account not only faults due to the physical components, but also the human factor.

In this paper, we give an overview of the comprehensive set of methods and tools developed so far and we sum up the lessons learnt after the application of our approach to several significant case studies.

Building simulable formal models of complex system and their failures

The first step of the ISAAC methodology is to build a formal system model that includes fault models with one of the following notations: Simulink, SCADE, Statemate, NuSMV and AltaRica. Two ways of building such formal failure propagation models were envisaged. In the first scenario, models are specially built for safety analysis purpose. So details regarding the normal behaviour are not modelled but rather a nominal abstract behaviour is modelled allowing for the focus to be placed on failures and their propagation. In the second scenario, formal design models exist because they were provided to support system functional analysis. They depict the expected system behaviour. These models are extended to deal with the failure propagation.

The following sections show how the ISAAC methodology and tools support both scenarios.

Failure propagation models based on predefined components

In the first scenario, we propose to assist the construction of a failure propagation model with the use of predefined libraries of formal components. The library of components is a collection of formal models of basic system components that are immediately suitable for safety analysis. Thus, each formal model describes both nominal and faulty behaviour of a specific system component and the model granularity is defined according to the safety analysis purpose.

In the earliest phases of the system design, details of physical components are not fixed and safety engineers work with simple functional blocks and functional failure modes, (eg. function permanent loss). Usually, a block offers a service (outputs) provided that some inputs and resources are available in the nominal case (see figure in section 4.1). Only permanent failures are considered and, after a failure, the block no longer provides an output. Some other blocks do not require inputs or resource to play their role (e.g., source of energy), or they do not provide any output (receptor). The library contains a first family of such generic blocks.

During the Preliminary System Safety Assessment (PSSA, [START_REF]Certification Considerations for Highly-Integrated or Complex Aircraft Systems[END_REF], [START_REF]Guidelines and methods for conducting the safety assessment process on civil airborne systems and equipment[END_REF]), the system architecture is developed, there is a greater understanding with regards to the behaviour of components, hence safety engineers take into account more specific failure modes. At this stage, the library currently contains two other families of components. One is dedicated to components of hydraulic systems (reservoir, pump, valve, pipe, …) and deals with failure modes such as total loss, leak in a component, leak propagation, … Second is dedicated to components of electrical systems (generator, bus, switch, receptor, …) and handle failures such as total, short-circuit, … A third family of components is under development to deal with a flight control system.

Whatever are the development phases, all these failure propagation models are qualitative ones. For instance, inside the hydraulic library, three levels of fluid (empty, low, normal) are considered instead of a real value, that measures the fluid pressure. The library is currently written in the AltaRica language [START_REF] Arnold | The AltaRica formalism for describing concurrent systems[END_REF]. Basically, each AltaRica model consists of two parts. An automaton describes which failure or nominal mode may be activated when a failure or a normal event occurs. Then, a set of logical assertions describes the relationship between the input/output of the components according to the current modes (see for instance [START_REF] Kehren | Advanced Multi-System Simulation Capabilities with AltaRica[END_REF]). The library is implemented within the Cecilia-OCAS graphical toolkit. A translator from AltaRica to Lustre language has been developed1 and will allow the ability to have similar libraries written in the Lustre language, usable in the SCADE environment

Failure mode extension

In the second scenario, the process is initiated by the design engineer, who provides a formal model of the design, the System Model (SM for short), at a given level of granularity. Initially the model includes only the nominal behaviour of the system, that is, all the components of the system are assumed to behave as expected. This model may be used by the design engineer to verify the functional requirements of the system, and it is then passed to the safety engineer for safety assessment.

The validation of the SM with respect to the safety requirements is performed by assessing the system behaviour in degraded conditions. To this aim, the safety engineer enriches the SM with the definition of the failure modes, that is, a specification of how the various components of the system can fail. This step yields a model, that we call Extended System Model (ESM for short). The ESM is an executable specification of the design model in which all the components of the SM can fail according to the specified failure modes. This step of the process is called Failure Mode Injection, and it is performed automatically through an extension facility.

The failure mode types to be injected into the SM can be stored and retrieved from a library of generic failure modes, the so-called Generic Failure Modes Library (GFML for short). This library contains the definition of the failures that can be attached to system model variables. Examples of typical failure modes are, e.g., stuck at (output stuck at a particular value), inverted (corruption of a Boolean output), ramp-down (decrease of a given amount at each execution step, down to a given value), random (non deterministic output), noise (a random offset in a given range is added to the nominal output). Attaching a failure mode to a system variable may require specifying additional parameters that affect the behaviour induced by the failure (e.g., the value which the variable is stuck at). The GFML may be extended to include user-defined failure modes. The SM together with the safety requirements and the injected failures constitute a safety task. Grouping these three types of information together allows for easy re-evaluation of a safety assessment in case of design changes.

An application of the method to a Flap Control System is given in [START_REF] Peikenkamp | Model-based Safety Analysis of a Flap Control System[END_REF].

Generic safety assessment activities revisited thanks to formal behavioural models and associated tools

We present now how to formally check whether a failure propagation model meets a safety requirement. Typical safety requirements are qualitative ones such as "no single failure shall lead to a failure condition" or quantitative ones such as the "the probability rate of the failure condition shall be less than 10-9 per flight hour".

Traditionally, safety analysts use a deductive approach to assess such requirements: starting from a failure condition (e.g. "function loss") as top level event, they progressively built a Boolean tree or a diagram that catches the combination of elementary events that caused the top level event. Then fault tree tools can compute the probability rate of the top level event to assess the quantitative requirements. They can also compute the set of minimal combinations of elementary events that lead to the top level to assess qualitative requirements.

With the ISAAC approach, the basic event dependencies are stored in the formal failure propagation model independently from any top level event. We use two basic techniques to exploit the formal models: model checking and generation of fault trees or sequences of events. Model checking enables to proof qualitative requirements whereas the generation tools extract from the model the set of causes of a failure condition. Let us give more details about these two techniques.

Model checking

Model checking is one method for the exhaustive verification of embedded reactive systems [START_REF] Huth | Logic in Computer Science -Modelling and reasoning about systems[END_REF]. It helps to find bugs that are difficult to find by testing, since they tend to be non-reproducible. This verification approach requires having at disposal three elements: 1. A system model SM. It is described within a framework for modelling the reactive system, e.g. description languages such as Statemate2 , SCADE3 .

2. A safety requirement Req. It is formally written in a specification language for describing the properties to be verified.

3. A verification engine to establish whether the description of the system satisfies the specification.

In the ISAAC context, the system model SM ( 1) is built as described in section 2. Whatever is the modelling framework, SM can be considered as a transition system that depicts how the system evolves from state to state. SM can also be viewed as streams of values for a period of time steps.

The specification Req ( 2) is usually given in some logical formalism. It is common to use temporal logic. The idea of temporal logic is that a logic formula is not statically true or false in a model SM. Instead the models contain several states and a formula can be true in some states and false in others. Thus, the static notion of truth is replaced by a dynamic one, in which the formulas may change their truth values as the system evolves from state to state.

The model checker (a programme) ( 3) is applied to the system SM and the property Req to be verified. It outputs the answer "yes" if SM satisfies Req (the definition of "satisfies" depends on the semantics of the temporal logic [START_REF] Huth | Logic in Computer Science -Modelling and reasoning about systems[END_REF]) and "no" otherwise; in the latter case the model checker produces a trace of the system inputs which causes the violation of Req. This automatic generation of such "counterexamples" (CEX) is an important tool and will be applied in the following chapters.

Fault tree and sequence

Let ESM be a formal failure propagation model that depicts how system variables X1, X2, … evolve in the course of time in nominal mode or when a failure mode FM1, FM2, … is active. Let SR be a safety requirement expressed by some temporal formula.

Let TLE be the top level event corresponding to the violation of SR. Then, the cause (fault-tree or sequence) generation analysis aims at finding out which combinations of FM can cause the violation of SR. The computation is based on the counterexample (CEX) generation of the proof engine previously described. One tries to prove that ESM fulfils SR. If ESM violates SR, then each CEX is a possible cause.

Thus, the analysis is done in the same fashion as traditional fault tree analysis (FTA), -i.e. one identifies minimal combinations of failures (Minimal Cut Sets) violating SR -but with the difference that traditional FTA is static whereas the ISAAC approach can also include temporal aspects. The figure 2 illustrates this difference.

Notice that input and output variables to ESM and SR represent streams of values for a period of time steps. This makes it possible to represent analysis results, see Figure 2, showing a sequence of values for each variable. When SR is violated it is of special interest to notice the FM's, which are included in the CEX.

Figure 2 Temporal vs. static methodology If there is no further interest in the CEX than observing the FM's -i.e. no attention is paid to which design variables (X) are included or to any sequences -the analysis result is interpreted in a traditional "static" way. This interpretation can be seen as an abstraction of the temporal approach and is illustrated in the right part of Figure 2.

Taking also the temporal information into account it is possible to perform a number of analyses, e.g. importance of ordering among FM's, duration of FM, influence of system state, etc. The CEX shown after an execution represent one possibility to violate SR and therefore it is of interest to concentrate and elaborate on the cut set found.

Looking at Figure 2 we see e.g. that FM1 occur before FM2 and we can be interested to know if their ordering is of importance. This type of analysis is done automatically by the ISAAC platforms.

In the CEX, in Figure 2 Another temporal aspect is to impose a "system state" under which the analysis shall be done. ISAAC platform makes it possible to define sequences of values for one or more of the design variables representing a system state. In the CEX, in Figure 2, we may impose X1 and X2 to be constantly set to true and still allowing only FM1 and FM2 to become true. If SR is still violated it indicates that FM1 and FM2 is a cut set under the specified system state whereas if no CEX is found the occurrence of FM1 and FM2 under the specified system state has no impact on SR.

Specialized analysis based on formal behavioural models

In the following it will be shown how the approach for performing safety analysis in the "ESACS environment", described in the previous paragraphs, has been reused during the ISAAC project in order to cover other safety related aspects, especially considered during the design phase, like: the safety requirements allocation, the testability and the mission reliability analyses.

Requirement allocation based on SAP

When designing a system, engineers have to decompose high level system requirements into finer requirements that will constrain system subparts. Such allocation of requirement is indeed strongly connected to the definition of the system architecture. So, in order to assist the allocation of safety requirements, we proposed to encode experts' know-how into formal model libraries of typical safety micro-architectures [START_REF] Kehren | Architecture Patterns for Safe Design[END_REF].

The micro-architectures models exhibit elements of interest for a safer design: 1) structural features (e.g. redundancy), 2) good use condition and 3) induced safety properties. They are indeed abstract views of the system safety elements and will be called Safety Architecture Patterns (SAP). Figure 3 gives two examples of patterns. On the right side, one can see a "testable basic block". The requirements allocated to this block are the following: it shall provide a health status "f" and an output "o" when it did not fail and it receives an input "i", an activation signal "a" and a resource "r". On the left side, one can see a cold spare redundancy mechanism made of two testable basic blocks C1 and C2 and activated by a controller that switches from C1 to C2.

C a r f o block i C 1 a 1 r 1 f 1 o 1 C 2 r 2 o cossap block block i 1 i 2 1 2 a 2 f 2 o 2 C a r f o block i C 1 a 1 r 1 f 1 o 1 C 2 r 2 o cossap block block i 1 i 2 1 2 a 2 f 2 o 2

Figure 3 -CoSSAP and Block

Such patterns are often used to tolerate one failure (guaranteed property) under good use condition (derived requirements for interface system) such as:

Activation of C1 and no failure of C1 always imply resource for C1

This derived requirement states that "when the primary component C1 is operational (because it is safe and activated), then it shall receive the resources that are necessary to provide the output".

In ISAAC, libraries of SAP are developed. Currently, the expected behaviours of a SAP are described within the AltaRica language whereas other associated requirements (good use conditions and guaranteed properties) are expressed by temporal logic formulae. Each SAP is pre-proved using the formal tools described previously, i.e. one verifies that under the expressed assumption of the SAP environment, the AltaRica model fulfils the guaranteed properties. Then the system model can be built as previously described. The novelty is that pre-defined safety requirements are made explicit and formal for further analysis.

Testability

With Testability we intend a design characteristic that allows the status (operable, inoperable, or degraded) of a system or an item to be determined and the isolation of faults within the system or the item to be performed in a timely manner. The Testability characteristics of a complex system are very important also from a safety point of view, especially in the aeronautical field. Here Testability plays an essential role both in flight, to guarantee safety level (switching off or reconfiguring faulty items or systems) and condition awareness to the pilots (status indication), and on ground, during maintenance and repair procedures.

The idea is then to reuse the two basic and complementary strategies for the evaluation of the effects of failure events on a system model that is the inductive or "bottom-up" approach and the deductive or "top-down" approach, to verify testability related requirements.

In ISAAC we set as our goal the implementation of two different kinds of testability analysis and namely the Fault Detection and the Fault Isolation analysis.

The objective of Fault detection analysis is to find if and how faults are detected.

With "detected" we mean the issue of a particular signal (or set of signals) every time that the fault shows (that is when the failure mode is activated). The Fault Detection analysis, in the environment described in section 2 and 3, considers as top level event the generation of a detection signal and uses the bottom-up approach in order to highlight if and how a given failure mode (or combination of failure modes) is detected in all the possible system's states.

A sub-case of Fault Detection Analysis is the False Alarm Analysis that consists in analysing if it is possible to activate a detection signal without the activation of any failure mode.

On the contrary the deductive approach (top-down approach) is followed in order to perform a Fault isolation analysis, that is, to see which combination of failure modes can lead to the activation of the given detection signal. The result of this analysis is a "causal tree", that is, a tree that relates the issuing of a detection signal with the causal failure modes.

Starting from the "causal tree", one or more reordering strategies (based on, for instance, the failure rate, the time to re-test each failure mode and so on) could be used in order to identify the most appropriate fault isolation sequence.

Mission reliability analysis

Mission analysis' target is to determine the impact of degraded situations on the system operational modes and over pre-defined missions that define the scenarios in which the system being developed will be used.

Data representation

In case of mission analysis, not only the "system" has to be represented, but also the "mission".

The suggested model architecture is indicated in the following figure where two main "charts" are represented in parallel. The first chart represents the system model.

A system that operates in a mission can be in different configurations depending on the mission phase. The "formal" model under this chart should therefore represent the system configurations and the transitions among them.

The second chart represents the mission model.

The mission has to be represented with its attributes: phases, transitions among them, duration and requirements.

An example of mission model, "Mission Manager", is indicated in the following figure.

Other aspects

In an operational context other aspects are relevant: like the occurrence of a particular risk (e.g. an engine disk burst) or a pilot error.

Therefore a comprehensive environment for mission analysis integrates also the techniques that are described in the following paragraphs 5 and 6.

5.

Coupling bevioural models of complex system and geometric models for particular risk analysis

Analysis of geometrical models

Geometric installation models of systems are created as the system is developed. Abstract blocks that serve as placeholders for components are initially introduced with subsequent refinements as more details regarding the components shape become available.

Particular risk models and trajectories are agreed with the authorities. The level of detail included in the models varies for each particular risk model.

3D modelling tools such as Catia or more specialised tools such as IRIS are used to cohabitate the systems installation geometry with the particular risk models and carry out a collision analysis.

The particular risk analysis type determines the parameters that are used to characterise each collision.

An example of a particular risk analysis model is uncontained engine rotor failure (UERF). Here the critical parameters are the Phi angle (roll angle) and the Khi angle (angle that the trajectory vector has with reference to the rotor disk plane). The resolution of the analysis depends on the distance from the fragment point of origin, the criticality of the effect and size of the accounted fragment. A failed rotor fragment from the Engine affects the components over a range of Phi and Khi angles. The risk window is then plotted for each component over the range. Defining the risk window for each component for the range of Khi and Phi angle within a sub-system and then overlaying them would give an idea of the level of redundancy the system has for each fragment.

The useful information from such an analysis includes the systems, structures and components that are simultaneously affected by each instance of a particular risk in addition to the energies that are involved; the spacing between the affected components, the probability of a trajectory being followed, etc. The relevant information used within the context of this project is related to the identification of groups of simultaneously affected components from all the systems that play a part in supplying the functionality that is stipulated by the safety requirement that is being analysed.

Coupling geometrical and behavioural worlds

We want to support the coupling of geometrical and behavioural models in both directions. From geometrical to functional world, we want to assess whether a trajectory computed with a particular risk tool is critical with respect to the system safety requirements. The set of items impacted by a trajectory is related with a failset i.e. a set of failures modes that are triggered simultaneously in the behavioural model. Once the behavioural model is extended with failsets, ESACS tools as described in section 3 can be used to check if the safety requirements are still valid.

We developed tools that define failsets based on particular risk results computed with tools as CATIA or IRIS and a table that relates geometrical and behavioural component names.

Work on the reverse direction (from functional to geometrical world) is under progress. Two capabilities will be developed: Visualisation of critical failsets into the 3D tools, Allocation to 3D components of requirements derived from the functional world analysis. These new capabilities could be used to guide the installation of equipments into the aircraft.

Coupling bevioural models of complex system and pilot models for human error analysis

The main objective of coupling behavioural models of complex systems and pilot models in ISAAC is to adopt the ESACS methodology to the requirements of an industrial Human Error Analysis (HEA). HEA in aerospace generally covers a multitude of areas from design, maintenance through to pilot behaviour. The general target of HEA in this project is to identify potential pilot errors and the safety impact on the overall flight.

Specific to ISAAC is the definition of a formal cognitive architecture of generic pilot behaviour. This architecture is capable to interpret/execute formal procedure models like takeoff or approach. Furthermore it is able to modify the procedure model based on a psychological plausible cognitive learning mechanism. These learned modifications may lead to pilot errors. Thus in the ISAAC-HEA the normative procedure models, also called mental models (MM), are extended by means of the learning mechanism, this leads to an extended mental models (EMM).

The focus is on mode errors, where an action is performed that is correct in some modes but not in the present one. Mode errors lead to "automation surprises", where an operator no longer understands what the system is doing. During the design the need for modes has to be balanced against the probability of mode errors. Generally a mode may be understood as a system configuration with a specific functionality. Modern avionics systems are equipped with a huge number of different modes. This allows the use of systems in a variety of different operating condition, but at the same time it becomes difficult for the operators to retain "mode awareness".

Lüdtke and Möbus [START_REF] Lüdtke | A Cognitive Pilot Model to Predict Learned Carelessness for System Design[END_REF] performed a simulator study with four pilots at the Lufthansa Flight Training Center. As a result they found that a subset of mode errors may be explained by "learned carelessness". This psychological theory [START_REF] Frey | Eine Theorie der gelernten Sorglosigkeit[END_REF] states that humans have a tendency to neglect safety precautions if this has immediate advantages, e.g. it saves time. Careless behaviour emerges if safety precautions (like checking the actual mode before pressing an auto pilot button) have been followed several times but would not have been necessary, because no hazards occurred. Then, people deliberately omit safety precautions because they are considered a waste of time. The absence of hazardous consequences acts as a negative reinforcer of careless behaviour. Learned carelessness is a process which is characteristic for human nature because we have to simplify in order to be capable to perform efficiently in a complex environment. We implicitly degrade our mental model to optimise it for routine situations. Unfortunately this may be disastrous in slightly deviating scenarios. Thus it is crucial to consider this process in system design.

Learned carelessness was modelled inside a cognitive architecture based on the mechanism of rule composition and tested by comparing the model behaviour and real pilot behaviour in different flight procedures. These trials showed that the model commits errors that comply with errors observed in the empirical study [START_REF] Lüdtke | A Cognitive Pilot Model to Predict Learned Carelessness for System Design[END_REF].

Starting from these initial results the cognitive architecture and simulation platform are investigated in ISAAC with further more complex procedures, like arrival and takeoff. With regard to learned carelessness the specific analysis question will be answered, if during the interaction with the design under investigation in specified scenarios the pilot is likely to simplify his knowledge about certain flight procedures and if these simplifications may lead to pilot errors and violations of safety requirements. In ISAAC this question is tackled by simulation and verification. A simulation platform is developed that integrates the cognitive architecture, a system design and a flight simulation software (for the environment) and allows to simulate the dynamic interaction of these models with different procedures (e.g. takeoff or approach) and scenarios (e.g. standard profile takeoff and extreme weather and terrain takeoff).

A procedure has to be uploaded onto the cognitive architecture. At the beginning of the analysis this procedure contains only normative rules allowing to always reach the procedure goal successfully. After each simulation run, that means after a procedure has been simulated and the goal was reached, the pilot model simplifies the procedure model according to learned carelessness. This leads to an EMM with potentially hazardous procedure rules leading to pilot error. After the EMM has reached a stable state it is translated into the formal notation of the system model. This enables to perform a fault tree analysis with the techniques described in paragraph 3 in order to identify all possible scenarios where the new procedure rules lead to pilot errors with an impact on the overall safety of flight. The resulting fault tree contains human errors as basic events and violations of procedure goals (e.g. the aircraft does not reach and maintain the initial altitude after takeoff) as TLE.

In ISAAC extensions of the cognitive architecture will be investigated. The architecture is extendible, because of its modular structure and because it is based on an established cognitive core components, that have been applied by various researchers to model a number of different cognitive mechanisms.

An additional benefit of having mental models and system models represented in a uniform framework is the ability to investigate mismatches between the two. In the ISAAC context this exploited by the identification of "cognitive inadequate system structures", i.e. system patterns that, although correct, are too difficult to operate on (e.g. because too much and/or too complex information needs to be kept in the mental model during operation). Thus, we cannot only investigate mental models as shown in [START_REF] Rushby | Using model checking to help discover mode confusions and other automation surprises[END_REF], but are also able to reveal weaknesses in the interaction between the operator and the system in terms of system features.

Applicability of the approach

The system modelling approach and the first version of the generic safety assessment tools presented in sections 2 and 3 were successfully applied to several case studies during the ESACS project. Currently, new tools versions and the extension presented in section 4, 5 and 6 are under test in ISAAC project. The lessons learnt so far are the following.

The case studies are extracted from existing aircraft systems.

Regarding, ESACS/ISAAC basic techniques, the sequences or cuts of failures computed in ESACS/ISAAC projects seem to have at least the same accuracy than the pre-existing ones. This is due to two factors. First, the tools can deal automatically with numerous detailed failure modes. The issue is rather to find out which level of details is the most appropriated with respect to the analysis purpose. Second, the tools can also provide more details about the temporal order between events that lead to a top level event.

Moreover, the approach really eases the dialog between safety engineers and system designers. Consider the possibility to show sequences of failures directly in a simulation model. This would help, in respect of usually huge Fault Trees, with the understanding of the system behaviour, providing evident support that the design satisfies the safety objectives.

It is worth noting also that the set of case studies is a significant sample of safety critical embedded system. It includes not only command systems that control aircraft mechanical components (e.g. flight control or landing gear systems) but also systems that provide resources for the others (e.g. hydraulic and electrical power generation and distribution). Thus the method seams to be applicable for a wide range of systems embedded not only in aircrafts but also on board of cars, trains or space vehicles.

Regarding newer experiments of ISAAC, they may testify of a wider application range. For instance, mission reliability analyse or the human error analysis require to deal with human models. Today, only results of preliminary tests are available. They shown the feasability of the new concepts; further results are expected to discuss the concept maturity and applicability in an industrial context.

Last but not least, the project partners promote the new methods towards the Authorities as applicable means of compliance for Certification purposes. For civil aircraft, the Certification process, as indicated in the Aerospace Recommended Practice -ARP 4754 "Certification Considerations for Highly Integrated or Complex Aircraft Systems", requires evidence that the safety requirements and objectives are satisfied by means of safety assessment analyses that are performed during all system development cycles. Usually Fault Trees, FMEAS… constitute the main elements for this evidence. ISAAC proposes formal models and the associated tools as additional means of compliance; these means are not referred today in the ARP documents.

Nevertheless, several general presentations of ESACS/ISAAC were already performed with good feedback from representatives of the certification authorities or in the SAE group in charge of updating the relevant ARP documents.

Moreover, Dassault Aviation chose to certify the flight by wire system of the Falcon 7x using the system model based approach. New steps in the certification process were defined and agreed both by European and American certification authorities. This is a first acceptance step. The next step is to register the underlying methodology in a forthcoming update of the ARP 4754/4761 document guide. DASSAULT AVIATION and AIRBUS will jointly support this activity in the next SAE comity session.

Conclusion

This paper has presented a safety assessment methodology based on formal modelling and reasoning methods. The methodology consists of two alternative approaches. First, the analysis can be performed directly on system design models (e.g. SCADE, Statemate or Simulink models) and merely extended, by analysts, by the injection of failure behaviour into model variables. Alternatively, the analysis can be based on formal safety models constructed by analysts; such models (normally expressed in AltaRica language) abstract from the "nominal" behaviour of the system and, instead, explicitly capture system behaviour in presence of failures. Both approaches allow automating traditional safety analyses (e.g. FTA). They also allow users (analysts) to undertake numerous "what if" investigations, for example to investigate whether the effect of a particular cut set is dependent on the order and/or duration of failure modes in the set. This paper has also described extensions to the baseline methodology that are being addressed in the ongoing ISAAC project.

There are two types of extensions. The first type further utilises the capabilities of model checkers and exploits the information contained in the models in order to deliver new types of analyses. This includes: assistance in allocation of derived safety requirements based on formal safety models and libraries of pre-defined "building blocks" -safety architecture patterns, mission reliability analysis that utilises the structure of the mission tree in order to provide more accurate predictions on reliability characteristics of the system and analyses concerned with the coverage achieved by health monitors and properties of such monitors (testability and detectability analyses). The purpose of this type of extensions is to maximise applicability of the ISAAC methodology at different stages of the design and assessment processes of safety critical systems, starting from early design, through to the later detailed stages of the PSSA.

The goal of the second type of methodology extensions studied by the ISAAC project is to extend the methodology to include different types of analyses in order to achieve better integration with what is often perceived as relatively independent and auxiliary analyses (e.g. CCA, PRA, etc) and in order to take advantage of the benefits gained from the use of formal methods in such analyses. Therefore, these extensions focus on increasing the scope of the models being analysed, or, to be more precise, by linking "core" behavioural models with both geometrical and cognitive models to allow analysis to cover the effects of common causes (due to the layout of equipment) and human errors (e.g. due to particular training procedures and typical operation profiles) respectively.

Finally, the ISAAC project is undertaking a number of purely methodological investigations in order to prepare theoretical grounds for yet further extensions. This includes a possibility to further utilise and extend capabilities of tools to analyse temporal aspects of the system behaviour and, thus, to provide analysts with a more detailed and precise description of how individual failure modes propagate and combine in the system eventually leading to unsafe conditions or behaviour. The investigations cover not only extensions to the tools but also extending traditional combinatorial analysis methods (e.g. FTA).

Both ESACS and ISAAC projects have included a variety of industrial partners -all leaders in European aeronautics market. Consequentially, the methodology has been applied to real industrial case studies and the results from the evaluation were quite positive and encouraging. Furthermore, one of the industrial partners has successfully negotiated with the European Aviation Safety Authority precise conditions for using the methodology to produce evidence for aircraft certification.

To conclude, it is important to note that although the project has focussed on aeronautics domain, nothing in the safety assessment methodology presented here cannot be successfully reused in any other industrial context that is concerned with safety critical systems, safety engineering and assurance.

Figure 1 :

 1 Figure 1: Safety task consisting of system model, safety requirement and injected failures.

Figure 4 :

 4 Figure 4: Model architecture for Mission Analysis

Figure 5 :

 5 Figure 5 : Mission Manager structure Qualitative analysis and results representation The techniques described in paragraph 3 can be used to find failure mode sequences responsible for mission failure or leading to violation of specific mission requirements. For the mission analysis purpose, the techniques are scaled up in order to include the possibility to define "observables" (e.g. mission phases) that are then used in the representation of the results. See the following figure.

Figure 6 :

 6 Figure 6: Results representation Quantitative analysis The failure modes sequences leading to the mission unsuccess with the relevant values for the failure rates can be used for performing the calculation of the Mission Reliability quantitative figure.

See http://altarica.labri.fr/Tools/AltaLustre/

see: http://www.ilogix.com/

see: http://www.esterel-technologies.com/

Acknowledgement

• The European Union that sponsored and funded ESACS and ISAAC projects • Several other people contributed to the work presented in this paper. We wish in particular to thank: M. Delpiano and M. Fabbri from Alenia Aeronautica, M. Mahrun, M. Fortes Da Cruz, M. Frisk, L. Goutal, D. Javeaux, C. Jourdan, F. Rezeaux, from Airbus, J. Karlsson and P. Persson from SAAB, L. Borgne from Prover, A. Sboner from IRST. We would also like to thank B. Lawrence and R. Knepper from Airbus for helping us improve this paper.


D Peters

Object

Object Oriented Framework for Test Automation

published or not. The documents may come   L'archive ouverte pluridisciplinaire

Introduction

By means of several abstraction layers the operation of the platform is simplified for the user. This is implemented by providing a set of classes and methods.

Platform and CMMI® Process

From the beginning the test automation platform TA3 has been developed in accordance with the CMMI® test process. Because of the open and flexible architecture of TA3 the platform can be adapted fast to new process requirements.

The development of an engine or transmission control unit (ECU) lasts from two to three years. Already during the development SW versions have to be delivered by the ECU suppliers to the car manufacturers in regular intervals. Already at that time SW quality has to meet the requirements. As a consequence a development life cycle is not only described with one V-cycle but with V-cycles for each version recurring behind each other.

The CMMI® SW test process in our organization defines, among other things, three phases which can be found in each V-cycle again: All test phases can be separated into the following classification:

• static and dynamic testing • manual and automatic testing

The test automation platform TA3 is used for all dynamic automatic SW tests under real-time conditions. In case of module verification TA3 is only used for special applications, whereas an external tool is used for standard unit testing.

The functionality of a control unit is permanently enlarged and changed. Already integrated and tested functionalities have to be checked again in each V-cycle. Because of that automatic regression tests are very important.

The tests with TA3 aren't pure black-box-tests but rather grey-box-tests. The internal structure of a SW module is not considered but, with the help of the application systems, the interfaces of a module are made visible and measurable. Furthermore the behavior of every function can be changed for testing by calibration systems. Due to this certain system states can be reached easier for testing. The validation of the calibration data is done by application engineers or by the car manufacturers.

Test Presentation Formats

In general test description formats can be subdivided into three categories:

• tabular test presentation • graphical test presentation • textual test presentation TTCN-3, the Testing and Test Control Notation, offers standard solutions for this area. It is used mainly in telecommunication area, but it also has the demand to be applicable for other areas.

All three TTCN-3 presentation formats are no execution languages. This means that each format has to be compiled to an execution language. Most tool suppliers use C++ or Java as execution language.

The tabular format of TTCN-3 was integrated only for compatibility reasons, i.e. for older TTCN versions, but no future is certified to it yet. Very often tabular test design is realized with Microsoft® Excel. An interpreter or compiler translates the Excel information into an execution language. This solution enables only sequential test flow. Control flow requirements (loops, decisions) are difficult to define in Excel, but this isn't target-oriented. Excel is a spreadsheet, not a program or script language. A further disadvantage of the tabular test design is that for every new feature a corresponding Excel syntax had to be defined first and the interpreter or compiler has to be enlarged. Therefore every new feature can be made available only after some weeks for the users.

The graphical presentation format of TTCN-3 is similar to UML TM , the modified modeling language. Due to the widespread use of UML TM and the new version UML TM -2.0 with the subset 'Testing profile' this solution is expected to be a standard. The use of UML TM as a graphic test design is primarily meaningful if UML TM is already used as standard method for SW development. Currently the TA3 framework does not offer the possibility to design tests with UML TM but, as preparation for this step, the frameworks may be developed with UML TM . The textual presentation format of TTCN-3 was analyzed in detail. Concrete test scripts were written in TTCN-3 and compared with other approaches. The evaluation showed a clear result. The TTCN-3 test scripts were cryptically and difficult to read. Some requirements could be fulfilled only with compromises. The strengths of TTCN-3, test of network communications, couldn't be used. The focus of TA3 when testing is the functionality of one ECU and not the networking of ECUs.

Standardization

Python is another script language which is widely used within in the automotive industries. But it cannot be described as standard textual description language.

At present there is no standard in the automotive industries, also not the three presentation formats of TTCN-3. UML TM-2.0 with the subset 'Testing Profile' has the potential to be a standard for the graphic description formats in the future.

For an organization it is very important to standardize the test presentation formats between their own development departments. This is a basic precondition for the reuse of tests and for considerable cost saving.

A general standard is important if tests have to be exchanged between organizations, e.g. between a car manufacturer and their suppliers. For instance, certain conditions, which have led to an abnormal behavior at the manufacturer, are to be reproduced at the supplier. These possibilities would be useful but are difficult to achieve.

The missing of a standardized exchange format is the minor problem. More important is that the HIL test systems and the closed-loop-models have to be identical. The manufacturers use different HIL test systems of different tool suppliers. These systems are no turnkey solutions. They are very specific configurations with extensive engineering services. Furthermore the complex closed-loop-models are not always accessible for the suppliers.

The identical installation of the car manufacturer test platforms at the suppliers cannot be the target. As there are numerous customers this would lead to a variety of systems at the ECU supplier, which cannot be maintained any longer. In addition, the reuse of tests within the own organization is more difficult.

The test focus of the car manufacturers should primarily differ from the test focus of the ECU suppliers. This means, the tests shall complete one another and not overlap. As a consequence of the exchange of tests should be a minor aim. Nevertheless there will be further efforts to support possible standards in the future. With a flexible architecture, the test automation platform can be extended by further presentation formats, thus also by possible future exchange formats. (see Figure 3: Expandability of TA3') Finally, there are other more important reasons for standardization: The control interfaces of the used tools are currently not standardized, not stable enough and functionally not completed. In the end standardization saves development efforts on driver layer.

Object-Oriented Framework

For the realization of a flexible test automation solution an object-oriented framework is one approach. A framework as a rule provides an application architecture unlike a pure class library. An objectoriented framework fixes the structure of essential classes and objects as well as a model of the control flow in the application. In this case frameworks are developed and used essentially with the aim to reuse architectural samples.

On the one hand a framework offers the possibility of general implementation of different requirements in the context of the test automation. The user is guided during the development of scripts regarding method. The target is fast realization from a test case to a running test execution script. On the other hand a framework is flexible. Special requirements can directly be implemented by the user themselves.

Test Class

The kernel of each test script is the test class. The tester derivates an own test class from the test base class and overwrites the four abstract methods 'init', 'stimulation', 'reset' and 'evaluation'. These four methods define the general test control flow and they are scheduled by the test base class. The tester defines only the test specific commands inside the overwritten methods. Therefore methods and classes are available in the framework.

Init

One group of classes and methods controls the test devices like HIL test systems, calibration and application systems or diagnostic tools. The classes on this level are independent from the particular use tool. In general the devices are addressed as follows: HIL-device, CAL-device or DIAG-device.

The test scripts therefore can be executed on different tools without adaptations. The classes of the framework relieve the tester as far as possible from administrative tasks, e.g. generation report entries, exception handling.

The other group of classes supports the tester in evaluation and generating reports.

The following example shows a test script and test report. These are the general steps:

• set of physical engine speed signal parameter on the HIL test system to 1000 rpm • set of physical pedal value signal parameter on the HIL test system to 50% • set of physical coolant temperature signal parameter on the HIL test system to 90°C • wait 5 seconds Test Script Presentation: The separation simplifies the generation of generic test scripts. One test script can be combined with different data sets to test, e.g. different variants of a SW configuration.

In addition, values of calibration constants and maps of the ECU can be parameterized via XML. They are loaded during runtime into the ECU.

Test Evaluation and Reporting

The automatic evaluation of dynamic signals is a specific challenge. The test scripts and especially the stimulation of test objects are running on the PC and with a non-real-time operating system. Furthermore, valid tolerances of the ECU operating system and sampling tolerances of the measuring system lead to divergent signal vectors.

These tolerances can be avoided by a relative temporal analysis of the signals. The complete evaluation is subdivided into evaluation sections. Due to separation the tolerance dependent parts can be excluded from the evaluation.

For most use cases a library of evaluation methods is available. If special requirements are necessary the developer can realize own evaluation algorithms HIL_C_N_PHY.set(1000, 'set engine speed for idle speed') HIL_C_PVS_PHY.set(50, 'set driver request for idle speed ') HIL_C_TCO_PHY.set(90, 'test of interface TCO') wait(5.0, 'wait for stable idle speed engine state') directly by means of Python. This is a further advantage of the Python language. Complex algorithm can be written but also easier test script control flows.

The expected behavior of the signal is passed to a method as list of parameters. The test is 'Passed' if the expected behavior of the signal lies within the defined tolerances. The method evaluates the current measured signal and generates a corresponding report entry. The test report information is saved as XML format during the test run. The test script itself doesn't contain report layout. It transfers only the test information into XML. The report layout is defined in so called 'style sheets'. Thus the report layout can easily be changed afterwards without any adaptations of the test scripts.

Modular Stimulation and Reuse

The economic success of the test automation depends very much on a possible reuse of automatic tests. The use of generic SW components doesn't immediately enable the use of generic tests.

During a test of generic functionality within a project the test has to consider the specific environment. The reuse can be improved by a consequent modular structure of the test scripts. The stimulation of a test object is not described completely in one test script. The stimulation is distributed in different stimulation classes in dependence of its functionality. This concept can be realized for example for SW integration tests. The modular structure of the SW is mapped one-to-one to the test script structure. The stimulation of an interface that is to be tested is carried out via a chain of stimulation classes.

Test Management

TA3 primarily is a test execution platform, but also covers test management aspects which are pointed out in the following:

The test script development process mentioned above is similar to the SW development process. Due to this the test scripts can be administrated with the same methods and tools regarding change and configuration management.

For further test management aspects the connection of the platform to an integrated product life cycle management is necessary. This results from the CMMI® demands on the product development. The open and flexible architecture of the platform supports this requirement.

Conclusion

Since the introduction of the Test Automation Platform TA3 in our organization the numbers of test automation projects and the numbers of users has jumped up. This trend results, among other reasons, in the ability to tailor the test automation platform to the specific processes and user profiles.

Efficient

Figure 1 :

 1 Figure 1: Architecture of TA3

Figure 2 :

 2 Figure 2: CMMI® SW Test Process

Figure 3 :

 3 Figure 3: Expandability of TA3

Figure

  Figure 5: Test Class Diagram

Figure 7 :

 7 Figure 7: Test Report Stimulation Example

Figure 8 :

 8 Figure 8: Test Report Example

Figure 9 :

 9 Figure 9: Modular Stimulation and Reuse Example', describes the difference between a non-modular and modular test script structure. Furthermore, the reuse of tests and stimulation scripts within a project and between two projects (Project A, Project B) is shown below.

  For test script development Python interpreter and debugger are used. Further utilities support the developer in generating test scripts. Test scripts can be parameterized with XML files; and test reports are generated automatically in XML format. The test hardware (test device) is controlled by call of corresponding instance methods in the test scripts. For this the test author doesn't need specific knowledge about the used test devices. Furthermore test scripts can be used unchanged on comparable systems from other suppliers.

Testing Automation Framework TAF User Test Scripts (textual presentation)

		other
		organizations
	UML: graphical presentation	Exchange Formats

  test script development is absolutely necessary because automatic tests don't selffinance. The high initialization efforts are compensated by the improved SW quality at a later date.Due to the open architecture the test automation platform is prepared to handle further requirements. Both, the embedding of new test equipment and the use of new test presentation formats can be realized quickly. The framework grows permanently with the new requirements.

		12. Author Biography
		Dipl.-Ing.(FH)	Dietmar
		Peters has been working for
		Siemens VDO since 1996.
		He is group and project
		leader and responsible for
		the	development	and
		introduction of the common
		test automation platform for
		all Siemens VDO Powertrain
		SW development locations
		worldwide.
		13. Glossary
	CMMI®	Capability Maturity Model
		Integration®
	CAL	Calibration
	DIAG	Diagnostic
	ECU	electronic control unit
	HIL	Hardware-in-the-Loop
	HW	Hardware
	Python	Script language
	MS Excel	Microsoft® Excel
	SW	Software
	TA3:	Siemens VDO SW Test Automation
		Platform
	TTCN:	Testing & Test Control Notation
	UML

TM : Unified Modeling Language TM V-Cycle Development Process Model XML Extensible Markup Language