Giter VIP home page Giter VIP logo

letsynchronise's Introduction

  • ๐Ÿ‘‹ Hi, Iโ€™m @eyip002
  • ๐Ÿ‘€ Iโ€™m interested in ...
  • ๐ŸŒฑ Iโ€™m currently learning ...
  • ๐Ÿ’ž๏ธ Iโ€™m looking to collaborate on ...
  • ๐Ÿ“ซ How to reach me ...

letsynchronise's People

Contributors

dependabot[bot] avatar eyip002 avatar mkuo005 avatar

Stargazers

 avatar  avatar

Watchers

 avatar

letsynchronise's Issues

Remove initial dangling dependency when system output is the receiver

receiveEvent: {task: "__system", port: "SystemOutput", taskInstance: 0,  timestamp: 1}
sendEvent:    {task: "task-c",   port: "out",          taskInstance: -1, timestamp: 0}

image

Don't save the dependency instance when receiveEvent.task == Model.SystemInterfaceName and sendEvent.taskInstance == -1

Import issue when reset on same file

To replicate do the following steps:

  1. Import a system file
  2. Export the system to the same filename
  3. Press Reset
  4. Import the same system file
  5. Database and views are not populated with data

Update database model for Dataflow

Example of definitions of dependencies in a format the View expects:

const dummyDependencies = [{'name': 'sensorDataflow', 'destination': 't1.in1', 'source': 't3.out1'}, {'name': 'actuatorDataflow', 'destination': 't1.in2', 'source': 't3.out2'}];

Example of instances of dependencies in a format that the View expects:

const dummyDataflows = [
{
'id': 1, // ID of dataflow instance
'name': 'sensorDataflow', // Original name of dependency
'receiveEvent': {
'port': 't1.in1', // Original destination of dependency
'taskInstance': 3, // Instance of destination task (1 indexing)
'timestamp': 4 // Timestamp of receive event (LET start of task's instance)
},
'sendEvent': {
'port': 't3.out1', // Original source of dependency
'taskInstance': 1, // Instance of source task (1 indexing)
'timestamp': 3.2 // Timestamp of send event (LET end of task's instance)
}
},
{
'id': 2,
'name': 'actuatorDataflow',
'receiveEvent': {
'port': 't1.in2',
'taskInstance': 3,
'timestamp': 4
},
'sendEvent': {
'port': 't3.out2',
'taskInstance': 1,
'timestamp': 3.2
}
},
{
'id': 3,
'name': 'actuatorDataflow',
'receiveEvent': {
'port': 't1.in2',
'taskInstance': 4,
'timestamp': 6
},
'sendEvent': {
'port': 't3.out2',
'taskInstance': 2,
'timestamp': 5.7
}
},
{
'id': 4,
'name': 'actuatorDataflow',
'receiveEvent': {
'port': 't1.in2',
'taskInstance': 5,
'timestamp': 8
},
'sendEvent': {
'port': 't3.out2',
'taskInstance': 2,
'timestamp': 5.7
}
}
];

Visualise LET schedule in Analyse view and model

  • Calculate the hyper-period of a set of tasks with initial offsets
  • Update ls.model.schedule to return task instances for a given makespan @mkuo005
  • Update ls.model.dependencies to return dataflows (dependency instances) for a given makespan @mkuo005
  • Show the task dependencies
  • Add tooltip information

See ls.view.schedule for an idea of how to create all task instances for a given makespan

// Replace with pre-computed values from ls.model.schedule
for (var instance = 1; periodStart < this.makespan; periodStart += taskParameters.period, instance++) {
// Add the task's LET duration
const instanceCopy = instance;
graphInfo.append('rect')
.attr('x', scale(periodStart + taskParameters.activationOffset))
.attr('width', scale(taskParameters.duration))
.attr('height', View.BarHeight)
.on('mouseover', function() {
d3.select(this)
.transition()
.ease(d3.easeLinear)
.style('fill', 'var(--blue)');
tooltip.innerHTML = `${taskParameters.name} instance ${instanceCopy}`;
tooltip.style.visibility = 'visible';
})
.on('mousemove', function() {
tooltip.style.top = `${d3.event.pageY - 2 * View.BarHeight}px`;
tooltip.style.left = `${d3.event.pageX}px`;
})
.on('mouseout', function() {
d3.select(this)
.transition()
.ease(d3.easeLinear)
.style('fill', 'var(--gray)');
tooltip.style.visibility = 'hidden';
});
// Add vertical line at the start of the period
graphInfo.append('line')
.attr('x1', scale(periodStart))
.attr('x2', scale(periodStart))
.attr('y1', `${View.BarHeight + View.TickHeight + View.BarMargin}`)
.attr('y2', `${View.BarHeight - View.TickHeight}`)
.attr('class', 'boundary');
}

Calculate response times of timing constraints

Related issues: #58 and #63

  • Design algorithm to find all instances of a timing constraint's event chain
  • Calculate end-to-end response time of each instance
  • Report the statistics of the end-to-end response times next to their respective timing constraint

Refactor the Current Scheduler into an AutoSync Plug-in

Current scheduler is defined in ls.model.schedule.js in method reinstantiateTasks.

  • When createTaskInstance is called, do not create executionIntervals
  • Only create executionIntervals in the scheduler plug-in according to the desired scheduling policy

Visualise Physical Execution Time in Task Schedule

  • Randomly generate execution times for task instances
  • Create naive schedule: Create a single execution time interval. Don't care about schedule correctness
  • Visualise execution times in task schedule
  • Implement Weibull distribution

Support Manual Updating of Displayed Task Schedule

model.task

  • Invoke a callback whenever refreshViews is invoked

view.schedule

  • Remove automatic updating of task instances when system is edited: Redrawing the schedule based on existing database contents is fine
  • Create a notifyChanges callback: Set the update button to warning colour
  • Change registerUpdateHandler to set the update button back to primary colour

view.analysis

  • Remove automatic updating of the schedule

controller.task

  • Register the callback with model.task

Update dependency definitions when a task is updated

When a task is updated, one of its ports may be removed. If this happens, dependencies associated with the port should be deleted.

  • Update ls.model.task.createTask(...)
    • Get all dependencies
    • Check if dependency source or destination task is equal to task name
    • If yes, check if dependency source or destination port still exists
    • If the port no longer exists, delete the dependency

Decide on File Import and Update Behaviour

Proposal:

  • A file could contain a system definition, a task schedule, or both
  • Unify the import and export functionality to a region above the design tabs: System Import and Export
    • Drop-down selection: import (file selection) or export
    • Drop-down selection: system, schedule, or all
    • Button: reset all

Create Relationship Class

Helper class that relates one type (instance) to another type (instance). For example, getting dependencyInstances of a dependency, getting taskInstances of a task, or get a dependency of a task.

Design Optimisation User Interface ("AutoSync")

  • Specify the optimisation constraints (goals): minimise response times or data ages
  • Specify scheduling preferences: rate monotonic, earliest deadline first, even out the workload, easy to accommodate future additions (max idle time)
  • Find the selected plugins: goal and scheduler
  • Button to start the optimisation
  • Display the optimisation progress and results: Use analysis functionality
  • @mkuo005 Implement as a LetSynchronise AutoSync plug-in:
    1. Load in default schedule to be optimised, e.g., from the end2end scheduling tool
    2. Compute the min and max of the scheduled start and end timestamp of task execution
    3. Edit LET task parameters:
    • Use the computed min timestamp as LET offset
    • Use the computed max timestamp - min timestamp as LET duration
    1. Update the schedule

Make Plugin "TU Dortmund" error more generic

  • Add documentation on how to use the scheduler plugin.
  • Make use of executionTiming when instantiating task execution times in the function static async Algorithm(system, executionTiming).

Create Time-Triggered to LET Transformer

Helper Functions:
* Parents(DepndencyDag, Task): 
  Returns the immediate parents of a task in a task dependency directed acyclic graph.
* Schedule(Task, LET, Offset):
  Returns a periodic static schedule for a task.
* E2ePaths(TaskCommunications, E2eConstraint):
  Returns all end-to-end paths between the input and output.
* PathLatency(Path):
  Returns the total execution and communication time of a path.
* AddMetric(Entity, MetricType):
  Calculates a score for each entity based on a metric calculation and adds it 
  as an attribute to the entity. 
  A positive metric could calculate an entity's flexibility, while a negative 
  metric could calculate an entity's penalty or severity.
* MostCommonTasks(Paths):
  Returns the tasks that appear most frequently in the given paths.
* MostSlack(Tasks, MetricType):
  Returns the task with most slack based on a metric calculation. The metric
  could be relative or absolute slack.
* GoTo(Step):
  Execution of the algorithm goes to the start of mentioned step.
* CumulativeMinAge(TaskSet, TaskCommunications, Task, TaskInput):
  Returns the minimum latency for an environmental input to arrive at a task.
* CumulativeMaxAge(TaskSet, TaskCommunications, Task, TaskInput):
  Returns the maximum latency for an environmental input to arrive at a task.


Algorithm: LET Scheduling
-------------------------
Given:
* task \in TaskSet: All LET tasks in the system. Assume physical inputs/outputs are tasks.
* task = {period, wcet}: Period and estimated WCET.
* (task1, task2, signal) \in TaskCommunications: Tasks that communicate via a signal.
* (input, output, time) \in E2eConstraints: End-to-end timing constraints.

Return:
* Either, the original task set with a feasible LET schedule, 
  or nothing if some timing constraints cannot be satisfied.


// 1. Create initial schedule
// Assume that all backward dependencies have been broken.
// Tasks that only depend on physical inputs are scheduled to start at time zero,
// and immediately dependent tasks are scheduled to start immediately after.
dependencyDag = DependencyDag(TaskSet, TaskCommunications);

for each task in dependencyDag:
  parents = Parents(dependencyDag, task);
  maxOffset = max(for each parent in parents: parent.offset + parent.period);
  
  task.schedule = Schedule(task, LET = PERIOD, maxOffset);


// 2. Rank all end-to-end paths specified in the system's end-to-end timing constraints
// There could be many paths between an input and its output. 
// Split the ranking based on whether timing constraints are violated.
// Paths that exceed their timing constraint are ranked by a normalised metric.
PathsViolated = [ ];  // (Path, ActualLatency, MaxAllowedLatency, MetricScore)
PathsRelaxed = [ ];
for each constraint in E2eConstraints:
  Paths = E2ePaths(TaskCommunications, constraint);
  for each path in Paths:
    pathLatency = PathLatency(path);
    if (pathLatency > constraint.time):
      append(PathsViolated, path, pathLatency, constraint.time);
    else:
      append(PathsRelaxed, path, pathLatency, constraint.time);

AddMetric(PathsViolated, NEGATIVE);
AddMetric(PathsRelaxed, POSITIVE);


// 3. Iteratively reduce the LET or period of tasks with the greatest amount of slack
// Could be effective to start with the most common task in PathsViolated.
// Fairness could be incorporated.
while PathsViolated is non-empty:
  CriticalTasks = MostCommonTasks(PathsViolated);
  criticalTask = MostSlack(CriticalTasks, ABSOLUTE);
  criticalTask.let = criticalTask.wcet;
  GoTo(Step 1);


// 4. Rank tasks with incoherent inputs
// Need to calculate the min and max ages of a task's inputs.
// An input's age can vary if task periods are not whole multiples of each other.
TasksInputIncoherent = [ ];
for each task in TaskSet:
  inputsMinAge = infinity;
  inputsMaxAge = 0;
  for each input in task.inputs:
    inputMinAge = CumulativeMinAge(TaskSet, TaskCommunications, task, input);
    inputMaxAge = CumulativeMaxAge(TaskSet, TaskCommunications, task, input);
    
    inputsMaxAge = max(inputsMaxAge, inputMaxAge);
    inputsMinAge = min(inputsMinAge, inputMinAge);
    
  ageMaxDifference = inputsMaxAge - inputsMinAge;
  if (ageMaxDifference > tolerance):
    append(TasksInputIncoherent, task, ageMaxDifference);

AddMetric(TasksInputIncoherent, NEGATIVE);


// 5. Terminate the algorithm if TasksInputIncoherent is empty
// Return the task set with its feasible schedules.
if TasksInputIncoherent is empty:
  return TaskSet;


// 6. Correct the incoherencies
// Corrections should be made as early as possible in each path for greatest
// flexibility.
while TasksInputIncoherent is non-empty:
  // TODO
  // Add communication delays to early inputs, or increase periods of predecessor tasks
  
  if changes were made:
    GoTo(Step 1);

  if all tasks in TasksInputIncoherent have been visited:
    return Null;



- - - - - - - - - -

Alternate idea:
---------------
Resolve incoherent inputs based on common tasks in PathsViolated.
Identify frontiers in the task schedule that constrain path delays.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.