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

[Oleg Sokolsky]

Julien,

I understand and share your concern about the type system.  We should 
indeed use component types as appropriate.  OTOH, when a component has 
internal structure, a system may be appropriate to describe it.  This 
happens a lot with devices, for example.  I wonder if you considered 
using the implemented-as construct here? It may reconcile the type 
system with the current modeling practice.

Thanks,
Oleg

On 04/02/2015 09:09 AM, Julien Delange wrote:
>
> 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