Criticality for other components than threads (processors, virtual processors, processes and subprograms)

[Etienne13]

Criticality property can be applied to threads and thread groups.

I think it would be interesting to enable to associate this property to other component categories:

• processors, and virtual processors, as a way to represent the certification level of the underlying platform
• processes as a way to represent the criticality of an application
• subprograms as a way to associate a criticality level at a lower granularity than threads

Proposed resolution: change

Criticality: aadlinteger applies to (thread, thread group);

to

Criticality: aadlinteger applies to (processor, virtual processor, process, thread, thread group, subprogram);

[jjhugues]

Check if the same question should be made for DAL property, Severity in EMV2

[Etienne13]

Note from the discussions with the committee:

• why not applicable to all categories?
• criticality is specific to scheduling concerns (and defined as applicable in the context of Maximum Urgency First the Thread_Properties.aadl) ; issue should be revisited with this in mind. Would this be extended to all categories then?

[jjhugues]

• [ ] Etienne, Check the categories in the context of scheduling
• [ ] Mark, Criticality as a scheduling concept, vs as a safety concept. We have DAL (ARINC653), Severity (restricted to error sources/sinks) in EMV2, and likelihood. We must homogenize these.

[jjhugues]

• [ ] should we add inherit? no, prefer to be explicit rather than using inherit mechanism
• [ ] what about system as category (because of using system to represent multicore)
• [ ] criticality to be a scheduling concern only, to be clarified in the definition of the property

Proposed update.

Criticality: aadlinteger applies to (virtual processor, process, thread, thread group);

[jjhugues]

@Etienne13 can you please propose an update to this property definition that I can integrate in the standard? Thanks