Static scheduling specification

[Etienne13]

The AADL standard defines properties for static scheduling:

• Sheduling_Protocol can be set to static.
• a frame_period property is defined as the period of the scheduling table

However, there is no property to define the scheduling table itself.

I would recommend to adopt similar properties as the scheduling table property of the ARINC653 annexe, and to define it as a core standard property.

Add in core:

--
-- The Execution_Slot type represents a record to specify a time -- slot/frame of a processor
--
Execution_Slot : type record (
Computation_Unit : reference (processor); Start_Time : Time;
End_Time : Time;);
--
-- Execution_Slots represents all the execution slots for the thread
--
Schedule_Table : list of Execution_Slot applies to (thread, thread group);

[jjhugues]

There are multiple questions here:

• shall we drop the ARINC653 specific one and define a generic one in the core for other cases like basic time triggered schedules?
• or drop it from the core?

[Etienne13]

I would suggest that we drop the ARINC653 specific one and define a generic one in the core.

BTW, looking at the one in ARIN653, it differs from the one I proposed in this issue. Adapting the ARINC653 property, it would look like this:

--
-- The Execution_Slot type represents a record to specify a time -- slot/frame of a thread
--
Execution_Slot : type record (
Executed_Component : reference (virtual processor, thread group, thread);
Duration : Time;);

--
-- Execution_Slots represents all the execution slots for the processor
--
Schedule_Table : list of Execution_Slot applies to (processor, virtual processor);

[jjhugues]

Note this might not be sufficient/, for instance if you want to capture the fact that a partition can be executed on multiple cores (a list of processor of virtual processor) depending on the pattern you follow.

Of course you may duplicate the execution slot but that would make the syntax complicated

[Etienne13]

You are right, if you don't want to duplicate the execution slots, the initial proposal would work if you replace

Computation_Unit : reference (processor);

by

Computation_Units : list of reference (processor);

However, it forces to define tables per threads and not per processor (the latter seems easier to me, at least for one core).

BTW, just thought of this: we can use a list of references after applies to ...

Schedule_Table => ([Executed_Component=>partition1; 100ms]) applies to processor1, processor2;

Would this be ok as well?

I was also thinking we may need to add the system category along with the processor category.

[yoogx]

This scenario is more complex than that.

For ESA, we needed to support schedules like this on (TS being a time slot, P a partition, C a core)

TS1: P1 on C1, P2 on C2, nothing on C3 and C4 TS2: P2 on C1 and C3, P2 on C4

We never found a satisfactory representation.

I would suggest we first write down all requirements first; then propose an update to all impacted documents. See also saeaadl/arinc653#4

[Etienne13]

I don't think there are thousands of way to specify schedule tables. You can define it as a:

1. a list of time slots, and for each time slot a list of pairs <executable component; list of execution resource>. This is how you formulate it in your example.
2. a list of threads, and for each one a list of pairs <time slot; list of execution resources> (my first proposal).
3. a list of execution resources, and for each one a list of pairs <time slot; list of executed components> (my last proposal).

Of course, we should discuss the different options and then decide.

For saeaadl/arinc653#4 it is a much simpler issue with which I fully agree.

[jjhugues]

Next step is for Etienne to propose an example for these options.

[Etienne13]

As a follow up on our discussions durint the AADL meeting, here is a more complete proposal along with a simple example.

Proposal:

property set proposal_issue_50 is

    --
    --  The Resource_Allocation_Slot type represents a record to specify a 
    --  slot of an execution resource (system, processor)
    --
    Resource_Allocation_Slot : type record (
        Execution_Resources : list of reference (system, processor);
        Slot : Time_Range;);

    --
    --  Resource_Allocation_Table represents all the resource allocation slots for the executed component (virtual processor, process, thread group, thread)
    --
    Resource_Allocation_Table : list of proposal_issue_50::Resource_Allocation_Slot applies to (virtual processor, process, thread, thread group);

    --
    -- The Component_Execution_Slot type represents a record to specify a slot of an executed component (virtual processor, process, thread group, thread)
    --
    Component_Execution_Slot : type record (
        Executed_Components : list of reference (virtual processor, process, thread group, thread);
        Slot : Time_Range;);

    --
    -- Component_Execution_Table represents all the component execution slots for the execution resource (system, processor)
    --
    Component_Execution_Table : list of proposal_issue_50::Component_Execution_Slot applies to (system, processor);

    --
    -- The Component_Execution_Slot type represents a record to specify a slot of pairs: 
    -- <executed components (virtual processor, process, thread group, thread), execution resource (system, processor)>
    --
    Static_Scheduling_Slot: type record (
        Executed_Components : list of reference (virtual processor, process, thread group, thread);
        Execution_Resources : list of reference (system, processor);
        Slot : Time_Range;);

    Schedule_Table: list of proposal_issue_50::Static_Scheduling_Slot applies to (system);

end proposal_issue_50;

Example (opt1 to 3 should match options 1 to 3 listed in my last comment) :

package example
public

    with proposal_issue_50;

    system multi_core
    end multi_core;

    system implementation multi_core.i
        subcomponents
            c1: processor core;
            c2: processor core;
    end multi_core.i;

    processor core
    end core;

    process p
    end p;

    system s
    end s;

    system implementation s.i
        subcomponents
            cpu: system multi_core.i;
            proc1: process p;
            proc2: process p;
    end s.i;

    system implementation s.opt1 extends s.i
        properties
            proposal_issue_50::Component_Execution_Table => ([Slot => 0 ms.. 5ms; Executed_Components => (reference(proc1), reference(proc2));])
                applies to cpu.c1;
            proposal_issue_50::Component_Execution_Table => (
                [Slot => 0 ms.. 5ms; Executed_Components => (reference(proc1), reference(proc2));],
                [Slot => 5 ms.. 10ms; Executed_Components => (reference(proc1), reference(proc2));]
            ) applies to cpu.c2;
    end s.opt1;

    system implementation s.opt2 extends s.i
        properties
            proposal_issue_50::Resource_Allocation_Table => (
                [Slot=> 0 ms.. 5ms; Execution_Resources => (reference(cpu.c1), reference(cpu.c2));],
                [Slot=> 5ms..10ms; Execution_Resources => (reference(cpu.c2));]                         
            ) applies to proc1, proc2;
    end s.opt2;

    system implementation s.opt3 extends s.i
        properties
            proposal_issue_50::Schedule_Table => (
                [Slot=> 0 ms.. 5ms; Execution_Resources => (reference(cpu.c1), reference(cpu.c2)); Executed_Components => (reference(proc1), reference(proc2));],
                [Slot=> 5 ms.. 10ms; Execution_Resources => (reference(cpu.c2)); Executed_Components => (reference(proc1), reference(proc2));]
            );
    end s.opt3;

end example;

[jjhugues]

Investigate whether we can rename property definition so that we define properties in the core, and another property sets may re-export this definition

[stevevestal]

I don't think we can forego annexes for specific standard scheduling methods. The ARINC 653 Annex goes beyond just defining a new property set. The use of those properties implies that all the semantics of the ARINC 653 standards are pulled in. Something similar would happen for other standards, such as MIL-STD-1553.

Something to consider is that a general core standard property, because it would not bring with it the specific semantics of an annex, would not be used in an annex unless the core standard semantics were sufficiently unconstrained to allow those semantics to be tailored in different ways for different other standards.

[jjhugues]

• [ ] @Etienne13 to review ARINC653 updates on this topic

[Etienne13]

As far as I could see, there is no specific update in the ARINC653 std when it comes to specifying XML configuration files for multi-core processors. However, after a second thought, I would favor option 2: it seems more consistent with the binding property of AADL, (which binds a process to a list of processors by applying the property to a process).