gilberto trivelato - ima

7/31/2019 Gilberto Trivelato - IMA

1/9

III Semana de Engenharia Aeronutica EESC USP - 2006

IMAIMA -- IntegratedIntegratedModular AvionicsModular Avionics

Agosto 2006

Airborne Computer Systems

III Semana de Engenharia Aeronutica EESC USP -2006

PROCESS WHAT IS IT?

People with skills,

training and motivation

Procedures and methods,

defining the relationshipof tasks

Tools and equipment

PROCESS

CMMI: Capability Maturity Model Integration

CMMI Guidelines


IMA - INTRODUCTION

1.1 Purpose

IMA system concepts are presented, including the platform and modules, and theirrelationships to the hosted applications and avionics functions used in an aircraftinstallation.

1.2 Scope

All parties involved in the development, integration, V&V of IMA systems is focused on IMA-specific aspects of design assurance (and may use incremental acceptance).

The primary industry-accepted guidance for satisfying airworthiness requirements for IMAcomponents: the a bility to obtain incremental acceptance of individual items of the IMAplatform (including the core software) and hosted applications enables the reduction offollow-on certification efforts without compromising system safety.


IMA - INTRODUCTION

1.3 Background

The evolution of software and microelectronics technology enables the introduction of newaircraft functions, new capabilities and increased levels of complexity. The need to performthese complex functions necessitates the use of high-performance computing platformsthat can host multiple applications on a single processor or a distributed network ofprocessors.

IMA is a shared set of flexible, reusable, and interoperable hardware and softwareresources that, when integrated, form a platform that provides services, designed andverified to a defined set of safety and performance requirements, to host applicationsperforming aircraft functions.


IMA - INTRODUCTION

1.4 Relationship to Other Documents

In addition to the airworthiness regulations and requirements, various national andinternational standards for software, avionics, complex e lectronics, and safety areavailable.

In some communities, compliance with these standards may be required.


IMA - INTRODUCTION

1.5 References

The latest versions of the following documents apply:

[1] RTCA DO-160 / EUROCAE ED-14, Environmental Conditions and Test Proceduresfor Airborne Equipment

[2] RTCA DO-178 / EUROCAE ED-12, Software Considerations in Airborne Systems andEquipment Certification

[3] RTCA DO-200 / EUROCAE ED-76, Standards for P rocessing Aeronautical Data[4] RTCA DO-201 / EUROCAE ED-77, Industry Requirements for AeronauticalInformation

[5] RTCA DO-248 / EUROCAE ED-94, Final Annual Report for Clarification of DO-178BSoftware Considerations in Airborne Systems and Equipment Certification

[6] RTCA DO-254 / EUROCAE ED-80, Design Assurance Guidance for AirborneElectronic Hardware

[7] RTCA DO-255 / EUROCAE ED-96, Requirements Specification for AvionicsComputer Resource (ACR


2/9


IMA - INTRODUCTION

[8] SAE ARP4754 / EUROCAE ED-79, Certification Considerations for Highly Integratedor Complex Aircraft Systems

[9] SAE ARP4761, Guidelines and Methods for Conducting the Safety AssessmentProcess on Civil Airborne Systems and Equipment

[10] FAA AC 20-148, Reusable Software Components

[11] FAA TSO-C153, Integrated Modular Avionics Hardware Elements

[12] FAA Order 8110.49, Software Approval Guidelines

[13] ARINC 615A, Software Data Loading

[14] ARINC 651, Design Guidance for Integrated Modular Avionics

[15] ARINC 653, Avionics Application Software Standard Interface

[16] ARINC 664, Aircraft Data Network

NOTE: When US Advisory Circulars are referenced, they are intended as material thatmay supply topics and areas for the applicant to consider. All requirements should becoordinated with the applicants local certification authority


IMA - INTRODUCTION

1.6 How to Use This Presentation

This presentation is intended to be used only internally.

This presentation recognizes that the guidelines herein are not mandated by law, butrepresent a some basic ideas of the aviation community.

This presentation is just a topics list introduction to the reader.


IMA - OVERVIEW

2.1 IMA Design AND Certification Terminology

See doc: IMA Design AND Certification Terminology

2.1.1 IMA Design Terminology

Aircraft Function

Application

Component

Core Software

IMA System

Interchangeability

Interoperable

Intermixiability

Module

Partitioning

Platform

Resource Reusable


IMA - OVERVIEW

2.1.2 Certification Terminology

Certification

TSO Authorization

Acceptance

Approval

Incremental acceptance


IMA - OVERVIEW

2.2 Architectural Considerations

a. Availability considerations

Functional performance

Resource management

Reliability and maintainability

Health monitoring

b. Integrity considerations

Design assurance

IMA safety and protection features

Fault detection and partitioning

c. Safety considerations

Safety assessment

d. Health monitoring and fault management, fault reporting, and recovery actions

e. Composability considerations

New function will not invalidate a property once that property has beenestablished

System properties follow from subsystem properties


IMA - OVERVIEW

2.3 Key Characteristics

The key characteristics of IMA platforms and hosted applicationsinfluence the IMA systemarchitecture, the detailed system design, and, ultimately, the IMA platform and systemacceptance process.

2.3.1Plat forms and Hosted Applications

a. Key IMA platform characteristics

Platform resources are shared by multiple applications

An IMA platform provides robust partitioning of shared resources

An IMA platform only allows hosted applications to interact with the platformand other hosted applications through well defined interface.

Shared IMA platform resources are configurable

b. Key Application Characteristics

An application may be designed independent of other applicationsand obtainincremental acceptance on the IMA platform independently of otherapplications

Applications can be integrated onto a platform without unintended interactionswith other hosted applications.

Applications may be reusable

Applications are independently modifiable.


3/9


IMA - OVERVIEW

2 .3 .2 Shared Resources

IMA systems may host several applications that share resources. Each shared resource hasthe potential to become a single point failure that can affect all applications using thatresource.

CPU(s) Memory

Associated interfaces

I/O devices

Data buses

Shared memory

Electrical power

Processor cycles

Bandwidth.

The IMA platform provides resource management capabilities for shared resources andhealth monitoring and fault management capabilities to support the protection of sharedresources.


IMA - OVERVIEW

2.3.3 Robust Part it ioning

Robust partitioning is a means for assuring the intended isolation and independence in allcircumstances (including hardware failures, hardware and software design errors, oranomalous behavior) of aircraft functions and hosted applications using shared resources.

2.3.4 Application Programming Interface (API)An API defines the standard interfaces between the platform a nd the hosted applicationsand provides the means to communicate between applications and to use I/O capabilities(ARINCs)

2.3.5 Health Monitoring and Fault Management

Health monitoring and fault management (HM/FM) functions deserve special attention dueto the integration of multiple applications and resource sharing. Unlike federated systems,IMA systems manage platform faults, hardware failures, partitioning violations, and errorsand anomalous behavior of hosted applications, including common mode faults andcascading failures.

The IMA platform provides health monitoring and fault managementcapabilities for theplatform and hosted applications.

The IMA system may provide health monitoring and fault management capabilities tosupport availability and integrity requirements.


IMA - OVERVIEW

2.4 Stakeholders

The assignment of roles and responsibilities is necessary, and should address the entireIMA system life cycle from conceptual design to retirement.

2.4.1 Certification Authority

The certification authority is the organization(s) granting approval on behalf of the state(s)responsible for aircraft or engine certification.

2.4.2 Certification Applicant

The applicant is responsible for the demonstration of compliance to the applicable aviationregulations, and is seeking a Type Certificate (TC), Amended TC (ATC), Supplemental TypeCertificate (STC) or Amended STC (ASTC).

2.4.3 IMA System Integrator

The IMA system integrator performs the activities necessary to integrate the platform(s) andhosted applications to produce the IMA system.


IMA - OVERVIEW

2.4.4 Platform and Module Suppliers

The IMA platform and module suppliers provide the processing hardware and software

resources, including the core software.

2.4.5 Applicat ion Supplier

The application supplier develops the hosted application and verifies it on the IMA platform.The application supplier should ensure that any hardware or software resources that areunique to the hosted a pplication meet the integrity and availability requirements consistentwith the assigned failure condition classification as determined by the aircraft systemsafety assessment.

2.4.6 Maintenance Organization

The maintenance organization follows the appropriate approved procedures received fromthe certification applicant to keep the IMA system and the aircraft in an airworthy condition.


IMA - GENERAL DEVELOPMENT CONSIDERATIONS

The development of an IMA system is based on an IMA platformcontaining hardware and software that are common and can be shared

by the hosted applications.

Back Plane

Power Supply

CPU & Memory

Data Bus

I/O

Real Time Executive

Built-in Test

On-boardMaintenance

System Protocol

I/O Processing

Application

ApplicationSpecific Software

CommonSoftware

ApplicationSpecific Hardware

CommonHardware

Typical HardwareModules

Typical SoftwareModules

Example of a typical design highlighting potential shared resources



The objectives of the IMA development process are to ensure that:

a. Aircraft functions allocated to a specific IMA system are consistent with the design ofthe system.

b. Aircraft safety and security requirements allocated to a specific IMA system areidentified and have been satisfied by the IMA design. This should include assignmentof system development assurance, hardware design assurance and software levels.These levels are determined by the aircraft-level safety assessment to support aircraftfunctions implemented by hosted applications and supporting availability andintegrity requirements, and any requirements for tool assessment and qualification.

c. Behavior of any hosted application is prevented from adversely affecting the behaviorof any other application or function by the design of the IMA platform. The platformhas robust partitioning, resource management and other protection meansappropriate to the aircraft functions and hosted applications.

d. Health monitoring and fault management functions of the IMA are provided for theplatform to meet specified requirements of the IMA platform.

e. Configuration management for the IMA platform, applications, integrator andcertification applicant are established and maintained .


4/9



a. Resource management of shared resources are developed and verified, includingaddressing periodic and aperiodic modification intervals, to ensure that modificationsdo not aversely affect the behavior of aircraft functions using these resources.

b. Dispatch requirements allocated to the IMA platform are implemented and verified.

c. Human factors requirements pertaining to the IMA system are implemented andverified.

d. An IMA System Certification Plan is developed that satisfies theobjectives of thisdocument and describes how this plan relates to other aircraft certification activities

and plans.



3.1 IMA System Development Process

These development process which should address, as a minimum:

a. The IMA platform Definition of reusable, sharable modules and resources

b. The hosted applications Definition of the interfaces and system contracts to allow agiven hosted application to reside on the given platform.

c. The IMA system Integration of the specific set of hosted applications onto a givenIMA platform(s).


IMA - OVERVIEW

3.1.1 Reusable IMA Platform Development Process

The IMA platform should be defined and developed independently of the specific aircraftfunctions and the hosted applications

a. Define the IMA platform concept

The architecture definition

An approach for integrating hosted applications, both hardware and software,onto the IMA platform.

An IMA platform acceptance approach.

An IMA system certification approach that includes support for hostedapplications and stakeholder roles and responsibilities for developingcompliance data.

A list of platform services to be provided to the hosted applications.

The intended level of aircraft functions availability and integrity needed,platform capabilities to support it and methods provided for supporting it.

The health management and fault management approaches

The platform and IMA system configuration management approaches.


IMA - OVERVIEW

a. Define the IMA platform requirements

Safety capabilities

Performance capabilities.

Configuration management approach.

Environmental conditions under which the platform modules are intended tooperate.

Fault management and reporting approach and requirements, includingconsiderations for: fault tolerance, fault isolation to modules, detection andisolation of single failures.

Detailed requirements for each aspect of the concept definition.

IMA platform architecture which has been defined and evaluated to therequired safety capabilities.

b. Develop and implement the IMA platform design.

The software and hardware development processes should follow DO-178Band DO-254 at the appropriate level to meet the required safety requirements.Additionally, common cause analysis (CCA) should be performed andqualitative failure analysis for the various top level events defined for the

platform should be developed.


IMA - OVERVIEW

a. Verify and validate the IMA platform addressing the following activities

Perform environmental qualification testing to the specified environmentalconditions.

Perform a partitioning analysis and verification testing; verifyother protectioncapabilities and safety features.

Complete the CCA.

Complete the numerical analysis showing that implementation meets thereliability requirements and capabilities.

Address modules sharing an environment and resources together.

b. Obtain IMA platform acceptance using the module acceptance approach

All IMA platform requirements should be validated and verified. Traceabilitybetween the requirements, implementation, and verification activities shouldbe developed and maintained.



3.1.2Hosted Application Development Process

Development of hosted applications follow the same development processes as used innon-IMA systems, but should address the following additional considerations:

a. Identify IMA platform resources to be used (part of interface definition).

b. Quantify required IMA platform resources (part of interface definition).

c. Map hosted applications safety assessment to IMA platform safety assessment andcapabilities (PSSA, FHA, CCA)

d. Define HM/FM requirements for the Hosted Application, define interactions with IMAplatform HM/FM functions.

e. Identify dedicated resources peripheral to the IMA platform.

f. Specify environmental qualification level for dedicated resources.

g. Human factors requirements should be assessed against IMA platform performance.


5/9



3.1.3IMA System Development Process

a. Identify aircraft functions, including functional requirements, performancerequirements, safety requirements, availability requirements, and integrityrequirements.

b. Allocate IMA platform resources to the aircraft functions considering the aircraft-levelFHA, resource requirements (interface specifications), safety capabilities of the IMAplatform and MMEL considerations. Determine what hosted applications or aircraftfunctions need isolation and/or protection from other hosted applications andfunctions and other protection mechanisms or safety features needed.



a. Develop the IMA system architecture, addressing the following aspects:

Develop IMA System Certification Plan based on aircraft requirements, hostedapplications and the IMA system certification approach.

Determine the quantity, quality and type of IMA platform modules and resources

needed to provide the capability to meet all application requirements, includingfunctional, performance, safety, availability, integrity, and redundancyrequirements.

Determine any aircraft function requirements driven by the capabilities of the

IMA platform modules.

Perform a Preliminary System Safety Assessment (PSSA) for each hostedapplication using the IMA platforms safety requirements.

Evaluate the aircraft effects from the combination of platform, hostedapplications and shared resource failures.

Identify changes required to the allocation of IMA platform resources to correctany issues identified from the individual and combined PSSA activities.



a. Implementation of the IMA system, including the following activities:

Develop the applications and perform partial verification.

Integrate applications onto the platform, complete platform core softwareverification, complete applications verification, and perform IMA system V&Vactivities, including application/platform integration testing (software, integrationtesting, hardware/software integration testing).

Develop initial IMA system failure analysis using IMA platform top level eventsas basic events for the hosted applications failure analyses.

Evaluate the combination of IMA platform component failures affecting hostedapplications which could lead to aircraft level effects, and adjust the allocationand/or applications implementa tion as necessary. (IMA platform componentfailures should have a unique top level event.)

Perform aircraft ground and flight testing to validate assumptions in the SSA,requirements and environmental definitions.



a. Integrate, validate, verify, and obtain acceptance of the IMA system (off aircraft).Specific configuration of applications in the IMA system should be shown to meettheir requirements (including performance, redundancy management, and IMAplatform interface requirements). Numerical analyses for each hosted applicationshould be developed to show it complies with its FHA. Additional ly, the hostedapplication numerical analyses should be combined into an IMA system hardwarenumerical analysis that shows that the combined events satisfy the aircraft levelsafety and reliability requirements

a. Integrate, validate, verify, and obtain acceptance of the IMA system installed on theaircraft.



3.2 IMA System Resource Allocation Activities

The aircraft functional and performance requirements influence the allocation of IMA hostedfunctions and meeting the safety, integrity and reliability requirements.

a. provisions for computing resource availability

b. application-specific I/O resources

c. network bandwidth

3.3 Aircraft Safety and Security

Safety requirements should be addressed in the IMA system requirements. Theserequirements drive the system configuration and the allocation of functions andhosted applications to IMA resources, and establish the independence, availability andintegrity requirements for those hosted applications contributing to the aircraftfunctions.

3.4 Design Assurance and Tool Assurance

The IMA system and components should be designed and developed to the highestassurance levels needed to support the safety, integrity and availability requirementsof the aircraft functions and hosted applications intended for the IMA system asdetermined by the IMA system safety assessment.



3.5 Partitioning and Resource Management Activities

Partitioning is a technique for providing isolation between functionally independentsoftware components to contain and/or isolate faults and potentially reduce the effortof the software verification process.

Robust partitioning should address the following information provided in DO-248/ED-94(Ref. [5], Section 4.1.4.5):

a. A software partition should not be allowed to contaminate the code, I/O, or data

storage areas of a nother partition

b. A software partition should be allowed to consume shared processor resources onlyduring its period of execution.

c. A software partition should be allowed to consume shared I/O resources only duringits period of execution.

d. Failures of hardware unique to a software partition should not cause adverse effectson other software partitions.

e. Software providing partitioning should have the same or higher software level thanthe highest level of the partitioned software applications.


6/9



3.5.1Design for Robust Partitioning

The design for partitioning in an IMA platform is an iterative process.

Robust partitioning services should provide the protection of the dedicated and sharedresources.

Failure of these partition services may lead to the generation of unintended failurepropagation paths.

3.5.2Partitioning Analysis

A partitioning analysis to demonstrate that no application or sub-function in a partitioncould affect the behavior of a sub-function or application in any other partition in anadverse manner.

All propagation paths between partitions should be identified.



3.6 Health Monitor ing and Fault Management

3.6.1 Components and aspects to be monitored

3.6.2 Health determination of each application

3.6.3 Health determination of the IMA system as a whole

3.6.4 Response to each type of failure

3.6.5 Flight Crew Annunciation and Messaging

3.6.6 Control of Maintenance Actions and Reporting

3.6.7 Redundancy Management

3.6.8 Single Event Upset (SEU) Faults



3.7 IMA System Configuration Management

3 .7 .1 Conf igur at ion Data

3.8 Guidance on Use of Shared Databases

3.9 Master Minimum Equipment List (MMEL)

3.9.1 Design Considerations for MMEL

3.9.2 Approval Considerations for an MMEL

3.10 Human Factors Considerations


IMA - CERTIFICATION TASKS

4.1 Overview of the Certif ication Process

4.2 Task 1 Module Acceptance

4.2.1 Module Acceptance Objectives

4.2.2 Module Acceptance Data

4.2.3 Module Acceptance Plan (MAP)

4.2.4 Module Requirements Specification (MRS)

4.2.5 Module Validation and Verification (V&V) Data



4.2.6 Module Quality Assurance (QA) Records

4.2.7 Module Configuration Index (MCI)

4.2.8 Module Acceptance Configuration Management (CM) Records

4.2.9 Module Acceptance Accomplishment Summary (MAAS)

4.2.10 Module Acceptance Data Sheet (MADS)

4.2.11 Module Problem Reports

4.2.12 Additional Module Acceptance Life Cycle Data



4.3 Task 2 Application Acceptance

4.3.1 Application Acceptance Objectives

4.3.2 Application Acceptance Data

4.4 Task 3 IMA System Acceptance

4.4.1 IMA System Acceptance Objectives

4.4.2 IMA System Acceptance Data

4.4.3 IMA System Certification Plan (IMASCP)

4.4.4 IMA System Validation and Verification Plan (IMASVVP)

4.4.5 IMA System Configuration Index (IMASCI)

4.4.6 System-level IMA Accomplishment Summary (IMAAS)

4.4.7 Other IMA System Life Cycle Data


7/9



4.5 Task 4 Aircraft Integration of IMA System (Including V&V)

4.5.1 Aircraft Integration Objectives

4.5.2 Aircraft-level IMA System Compliance Data

4.5.3 Aircraft-level IMA System Certification Plan (IMASCP)

4.5.4 Aircraft-level Validation & Verification Plan

4.5.5 Aircraft-level IMA System Configuration Index (IMASCI)

4.5.6 Aircraft-level IMA Accomplishment Summary (IMAAS)

4.5.7 Other Aircraft-level Data



4.6 Task 5 Change of Modules or Applications

4.6.1 Changes to IMA System Modules, Resources and Applications

4 .6 .2 Change Objectives

4.6.3 Change Management Process

4.6.4 Change Impact Analysis (CIA)

4.6.5 Cha nge Da ta



4.7 Task 6 Reuse of Modules or Applications

4.7.1 Objectives of the Reuse Process

4.7.2 Reuse of a Software Module or Application

4.7.3 Reuse of a Complex Electronic Hardware Module or Application

4.7.4 Reuse of Environmental Qualification Test Data

4.7.5 Reuse of a Module that Contains Software and Hardware

4 .7 .6 Reuse Compl iance Data


IMA - INTEGRAL PROCESSES

5.1 Saf ety Asse ssment

5.1.1 Responsibilities of the Certification Applicant

5.1.2 Responsibilities of the IMA System Integrator

5.1.3 Responsibilities of the IMA Platform Developer

5.1.4 Responsibilities of the Application Developer

5.1.5 Safety Assessment Activit ies

5 .2 System Development Assur ance

5 .2 .1 Sof twar e Guidance

5.2.2 Electronic Hardware Guidance

5.2.3 Integration Tool Qualification

5.2.4 Shared Design Assurance

5.2.5 IMA System Configuration Management

5.2.6 Environmental Qualification Testing

5.3 Validation

5.4 Verification


IMA - INTEGRAL PROCESSES

5 .5 Conf igur at ion Management (CM)

5.5.1 IMA System Configuration Management Plan

5.5.2 Configuration Control

5.6 QUAL ITY Assura nce

5. 7 C ert if ic atio n L ia ison

5.7.1 Certification Liaison Process

5.7.2 Means of Compliance and Planning Data

5.7.3 Development Life Cycle Data

5.7.4 Compliance Substantiation

5.7.5 Life Cycle Data Submittals

5.7.6 Certification Liaison Process When Changes Are Made

5.7.7 Certification Liaison Process For Reuse of Modules


SYSTEMS

6.1 Training

6.2 Maintenance

6.3 Post Certification Modif ications


8/9


IMA EXAMPLE 1: Single LRU Platform

Configured single LRU platform

API

CORE SOFTWARE

CPUs

&MMU

MEMORY

C

ONFI

G

.TAB

LES

PAR

TITI

ON

PAR

TITI

ON

PAR

TITI

ON

PAR

TITI

ON

...

PowerSupply

SpecificHW

I /O I /O I /O I /O I /O I /OI/O

NE

TW

ORK


IMA EXAMPLE 1: Single LRU Platform

Typical design of a single LRU platform containing:

a. Hardware: CPU, MMU, network interface and I/O

b. Software: Core software and partitioned application software

c. Configuration tables: partition definition, network port allocation, I/O mapping

Key characteristics of IMA found in this system:

a. A stand-alone platform or as a module for use within a larger IMA system.

b. The core software manages multiple software partitions, and provides robustpartitioning between applications.

c. Robust partitioning of the network interface

d. The LRU is adapted to ensure the CPU time, memory and I/O requirements ofeach software application.

e. Another key characteristic is a high level of internal fault/failure detection.


IMA EXAMPLE 2 - distributed IMA platform

Distributed modular platform

GeneralProcessingModules

PartitionedNetwork Resource

Communication Module

Input/OutputModules


PowerSupply

Modules




Definition of platform and modules

The platform in this example consists of three standard hardware boards, each designed toprovide a defined set of functions when assembled in accordance with the modularsystem architecture:

a. the General Processing Module (GPM)

b. the Power Supply Module (PSM)

c. the I /O Module (IOM)

In this example, all boards share a common structure, containing:

a. a Processor Module (potentially partitioned as described in first Example)

b. a Communications Module (robust partitioning of communication resource)

c. a functional block (application-specific to each of the hardware board)

The platform also uses core software components, which provide a

uniform API to applications:

a. a real-time operating system module

b. a fault management, and

c. a health-monitoring component




a. Sharing of resources, Robust Partitioning

b. Hosting of multiple applications, Re-qualification impact, Composability

c. API between platform and applications

d. Platform configuration data

e. Fault Management, Health monitoring


system

Distributed complex modular avionics system

SENSOR

EFFECTOR

SENSOR

EFFECTOR

SENSOR

EFFECTOR

SENSOR

EFFECTOR

FEDERATEDLRU

FEDERATEDLRU

DISTRIBUTED COMPLEX MA SYSTEM

DISTRIBUTED MA SUBSYSTEM

DISTRIBUTED MA SUBSYSTEM

RIU

RIU SWITCH

SWITCH

RIU

RIU SWITCH

SWITCH

RESOURCE CENTER

RESOURCE CENTER

SWITCH

SWITCH

SWITCH

SWITCH

CPM

CPM

CPM

IOM

CPM

CPM

CPM

IOM

HOSTEDAPPLICATIONS

HOSTEDAPPLICATIONS

OTHERCOMPLEX MA

SYSTEM

SENSOR

EFFECTOR

SENSOR

EFFECTOR

solid line connections indicate datatransfer network


9/9


system

Typical design of a single LRU platform containing:

a. Computing resources

b. Data transfer network

c. Remote I /O Units


a. Fault Management, Health monitoring.