[aadl]: [aadl-modeling]: Modeling of ARINC653 multicore systems

[Julien Delange]

Hi Pierre,


1.       The text should be “does not capture the hardware nature of the main processor” (not the core). When using a system to represent the processor, the semantics of the system is not supposed to capture a hardware component but rather a “box”. Using a processor for both the core and the main cpu would show that these are hardware component.

2.       I am not mentioning any particular tool. I am assuming that now, analysis tool consider a processor as a processor component, not a CPU. From a semantics point of view, it would make sense to keep the processor component to model the physical processor. I am just advocating against using the system to model everything: this would then remove the type system system of AADL – using a system for many modeling pattern is (from my perspective) a bad idea.
Also, the proposed changes could be for AADL v2.2 or AADLv3. The main motivation was to capture multicore for ARINC653 systems. The ARINC653 part related to multicore is not yet standardized, so, there are time from our end. But I would prefer to initiative the changes so that our core language is ready when we need to make additions to the ARINC653 annex.

3.       I do not say this is an issue but I think that using a system for modeling a processor is probably not the best solution from a semantics point of view, especially when we have a processor component type.
If we keep using the system for everything, one can wonder why do we have component types and just use system type for everything. We might then have a poor semantics with a box for everything.

4.       I think this point has been discussed/addressed in the previous comments.

Julien.


From: aadl-modeling-bounces+jdelange=sei.cmu.edu at lists.sei.cmu.edu [mailto:aadl-modeling-bounces+jdelange=sei.cmu.edu at lists.sei.cmu.edu] On Behalf Of Pierre Dissaux
Sent: Thursday, April 02, 2015 3:24 AM
To: AADL Modeling; sae-aadl-users at lists.sei.cmu.edu
Subject: Re: [aadl-modeling]: Modeling of ARINC653 multicore systems

Hi Julien,

I didn’t follow the discussions on that topic during the last meeting, but I well remember that the second option in your paper (System with Processors) was approved by the committee at the Winter 2014 meeting in Toulouse.

So, we do have a solution today to model multicore systems with or without virtual processors.
I will just comment the “Cons” you have identified for this current solution (§2.2 in your paper):

1. Do not capture the hardware nature of a core and potential interactions with buses. This might be critical
when analyzing the timing and shared resources of a core.

The core is represented by a processor. Why do you say it does not capture its hardware nature ?

2. Backwards compatibility of analysis tools (some analysis tools will not consider a system as a processor)

Which tool are you mentionning ?
We have no problem with that in AADL Inspector (Cheddar, Marzhin, ARINC 653 checker).
The changes we had to make one year ago to support systems as computing resources were very light.

Changing the components composition rules in the standard would have a much stronger impacts on both modelling and verification tools.

3. Compatibility of properties: properties using the processor as the OS needs to be updated. In that case, OSrelated
properties must also apply to system components then.

This has already been done for the Scheduling_Protocol
It is not a big issue to update a few property definitions if required

4. Lack of semantics: use the system as a container whereas a processor is a physical entity

This is a matter of point of view
A system can already have a Scheduling_Protocol, contain processors and virtual processors: it can actually be seen as a computing resource.
It also has all the required flexibility to incorporate complex architectures with buses and devices if necessary.

Moreover, the discussion we have today about processors could be extended to buses or devices. In all the cases, the system allows for a white box representation of complex hardware components.

Best regards

Pierre

From: Julien Delange<mailto:jdelange at sei.cmu.edu>
Sent: Wednesday, April 01, 2015 8:39 PM
To: AADL Modeling<mailto:aadl-modeling at lists.sei.cmu.edu> ; sae-aadl-users at lists.sei.cmu.edu<mailto:sae-aadl-users at lists.sei.cmu.edu>
Subject: Re: [aadl-modeling]: Modeling of ARINC653 multicore systems

My apologies, please find the attachment.

Julien.


From: aadl-modeling-bounces+jdelange=sei.cmu.edu at lists.sei.cmu.edu<mailto:aadl-modeling-bounces+jdelange=sei.cmu.edu at lists.sei.cmu.edu> [mailto:aadl-modeling-bounces+jdelange=sei.cmu.edu at lists.sei.cmu.edu] On Behalf Of Julien Delange
Sent: Wednesday, April 01, 2015 2:18 PM
To: sae-aadl-users at lists.sei.cmu.edu<mailto:sae-aadl-users at lists.sei.cmu.edu>; AADL Modeling (aadl-modeling at lists.sei.cmu.edu<mailto:aadl-modeling at lists.sei.cmu.edu>)
Subject: [aadl-modeling]: Modeling of ARINC653 multicore systems

Dear all,

As discussed during the last meeting, please find a white paper that explains the modeling of multicore systems for ARINC653 architectures and motivates having processor subcomponents in process components types.

Julien.

-------------- next part --------------
HTML attachment scrubbed and removed