robust partitioning

www.thalesgroup.com

Ensuring robust partitioning in multicore platforms for IMA systems Marc Gatti, Xavier Jean, Laurent Pautet, Thomas Robert, David Faura 2012/10/16 DASC 2012 - Williamsburg

2/

From federated to IMA systems

From physical to logical fault isolation

3/

‹

Federated systems }

Physical fault confinement

‹

Integrated systems }

Logical fault confinement: robust partitioning

Integrated Modular Avionics: Mandatory requirements

4/

‹

Robust partitioning

‹

Platform determinism

‹

Platform limitations for WCET scenario definition

Why ensuring robust partitioning is difficult on multicore platforms ?

Multicore for IMA, “good properties”

5/

‹

How could Avionics Platforms take benefit of multicore processors ? }

Allow all cores to be used whatever the level of criticality

}

Minimize porting effort and recertification of legacy applications

}

Compatibility with ARINC 653 and ARINC 664 guidelines for APEX and Network partitioning

}

Incremental certification

Digital avionic systems confidence have never regressed during technological steps

Robust Partitioning in avionic systems

6/

‹

Gold Standard for Robust Partitioning: “A partitioned system provides a fault confinement level equal to its functionally equivalent federated system” John Rushby

‹

Stronger property: Alternative Gold standard for Robust Partitioning: “The behavior and performance of software in one partition must be unaffected by software in other partitions” David Hardin, Dave Greve and Matt Wilding

Alternative Gold Standard is the easiest way to ensure Robust Partitioning

Robust partitioning in ARINC 653

7/

‹

Current process

‹

Time and space partitioning }

Disjoint memory areas for each partitions

}

Full allocation of processing resources to one process in one partition at one time

}

Targets the Alternative Gold Standard for Robust Partitioning

Partitions deployment on Multicore

8/

‹

Symmetrical Multi Processing :

‹

Time and space partitioning remains unchanged at partition level

‹

Inter-process conflicts impacts WCET

‹

Requires parallelization of single-core applications

Constraints are shared between Function Supplier and Platform Supplier

Partitions deployment on Multicore

9/

‹

Asymmetrical Multi Processing :

‹

Inter partition and applications conflicts when accessing shared resources

‹

Backward compatibility with legacy applications

Main constraints are at Platform Provider level

10/

Robust partitioning in a multicore platform

Partitioning issues on COTS multicore platforms

11/

‹

Timing issues and inter-core conflicts }

Transaction collisions in the interconnect

}

Shared caches

}

Shared I/O

‹

Limited knowledge of the interconnect features

‹

Nearly impossible to determine all situations of collisions

‹

Hardware mechanisms to avoid transaction collisions impact average performances

Alternative Gold Standard seems difficult to ensure if the hardware has not been developed for it

Gold Standard enforcement

12/

‹

Direct proof of robust partitioning }

Requires a generic model of faults for partitions

}

A priori, we have to consider all couples of faults to ensure no propagation

Highly complex analysis that have never been performed

Inter-core conflicts and robust partitioning analysis

13/

‹

We have to consider many possible sequences of conflicts

‹

Fault propagation result from sequences of inter-core conflicts

‹

}

For each fault, we determine the set of resulting conflicts classes

}

For each fault, we determine the set of causing conflicts classes

If those two sets are disjoint, robust partitioning is proven

Model of multicore platform

14/

‹

Abstract representation of the platform internal activity

‹

We have to deal with the lack of information }

‹

Model refinement with the available information

We can represent conflicts situations }

Simultaneous presence of two transactions in one component

Core refinement

15/

‹

Core Software }

‹

Core controller }

‹

Internal controllers, memory protection units, exception and interrupts generator

Local Memory }

‹

Can be a hypervisor, its execution is local

Internal caches and scratchpads

Partitions }

Transactions generator

Interconnect refinement

16/

‹

Each component has a pool of transactions it can handle }

‹

This enables to represent many behaviors inside the interconnect

Black box sub-components cannot be refined

Conclusion

17/

‹

‹

‹

The use of multicore in avionics requires new methods to enforce robust partitioning }

ARINC 653 time partitioning is not applicable

}

Inter-partition true parallelism

}

Concurrent transactions management in the interconnect with few visibility on its behavior

}

Incremental certification objectives

Two strategies to enforce robust partitioning: }

Control transactions flow emission in the core with the hypervisor

}

Represent transactions flow management in the interconnect

Those two strategies are complementary to authorize parallelism in partitioned systems

18/

Thanks for your attention !

Source: http://asrs.arc.nasa.giv/publications/callback/cb_330.htm