Difference between pages "Extending the Static Checker (How to extend Rodin Tutorial)" and "Rodin Workshop 2021"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Pascal
 
 
Line 1: Line 1:
{{Navigation|Previous= [[Extending_the_Static_Checker(How_to_extend_Rodin_Tutorial)]] | Up= [[Plug-in_Tutorial|How to extend Rodin Tutorial (Index)]] | Next= }}
+
==9th Rodin User and Developer Workshop==
  
=== In this part ===
+
The 9th Rodin User and Developer Workshop, 8 June, 2021, Ulm, Germany (Virtual)
  
We will see how to add rules to statically check the machines after our extension. The Static Checker (SC) is one dedicated part of the Proof Obligation (PO) generation process. Indeed, the POs are generated from the statically checked version of the model taken into account. Hence, we have to ensure before creating POs, that the model is correctly expressed (i.e. POs are generated for a model which "''could'' have some sense"). This means that we have to verify some additional properties on the newly added elements. <br>
+
''The proceedings of the workshop is now available as a [technical report] at the University of Southampton.''
The question addressed here is: " '''Under which conditions (about the model well-formedness) the PO generation means something?''' ".<br>
 
Additional information is available [http://wiki.event-b.org/index.php/Extending_the_Static_Checker here].
 
  
=== Principles ===
+
The programme now available on [https://abz2021.uni-ulm.de/program-overview  the ABZ2021 website] and [[#Programme|below]] (with texts).
  
1. To extend the static checker in order to verify some conditions, one has to '''define a static checker module''' using the extension point <tt>org.eventb.core.scModuleTypes</tt>.<br>
+
Event-B is a formal method for system-level modelling and analysis. The
There are two types of modules: <tt>processorType</tt> and <tt>filterType</tt>. We will detail the way to define such modules later.<br>
+
Rodin Platform is an Eclipse-based toolset for Event-B that provides
2. Then, one has to '''set up a configuration''' involving these modules and giving them a hierarchy. In fact, verifying the correctness conditions about added elements can be separated in several processor and filter modules; the configuration is then used to organise them.<br>
+
effective support for modelling and automated proof. The platform is open
3. Finally, it is needed to '''add this configuration''' to the default one, so our checks can be performed.<br>
+
source and is further extendable with plug-ins. A range of plug-ins have
 +
already been developed.
  
=== Step 1: Extending the database to introduce the static checked version of the element ''Bound'' (a.k.a. SCBound) ===
+
The 9th Rodin workshop will be collocated with the [https://abz2021.uni-ulm.de/ ABZ 2021 Conference].  
  
The aim of static checking is to produce a static checked version of the model upon consideration. Hence, every element ("unchecked") shall have its statically checked counterpart. We will then add the counterpart of the element <tt>Bound</tt>, following the same steps as when we added our element <tt>Bound</tt> in the database (See step 4 [[Extend_Rodin_database_(How_to_extend_Rodin_Tutorial)|here]]).
+
The purpose of this workshop  is to bring together existing and potential
 +
users and developers of the Rodin  toolset and to foster a broader community
 +
of Rodin users and developers.
  
To do so, create a new extension <tt>internalElementType</tt> from <tt>org.rodinp.core.internalElementTypes</tt> with:<br>
+
For Rodin users the workshop will provide an opportunity to share tool
- id: <tt>scBound</tt>,<br>
+
experiences and to gain an understanding of on-going tool developments.
- a name such as "Event-B Static Checked Bound Element",<br>
+
For plug-in developers the workshop will provide an opportunity to showcase
- a class for this element that extends <tt>SCExpressionElement</tt> and implements a freshly created interface <tt>ISCBound</tt> defined as follows:
+
their tools and to achieve better coordination of tool development effort.
  
public interface ISCBound extends ISCExpressionElement, ITraceableElement {
 
 
IInternalElementType<ISCBound> ELEMENT_TYPE =
 
RodinCore.getInternalElementType(QualProbPlugin.PLUGIN_ID + ".scBound");
 
}
 
  
=== Step 2: Adding modules===
+
=== Programme ===
  
==== Generalities ====
+
'''09:00 - 10:30'''
In our case of probabilistic reasoning, the following '''well-formedness conditions should be held''' for a model ''containing probabilistic events'':
+
* Domain knowledge as Ontology-based Event-B Theories - ''I. Mendil, Y. Aït-Ameur, N. K. Singh, D. Méry, and P. Palanque'' ([[Media:RodinWorkshop2021_Domain knowledge as Ontology-based Event-B Theories.pdf|pdf]], [[Media:RodinWorkshop2021_Domain knowledge as Ontology-based Event-B Theories_slides.pdf|slides]])
# The variant V (declared as usual) shall be either of type integer or some set.
+
* OntoEventB: A Generator of Event-B contexts from Ontologies - ''Idir Ait-Sadoune'' ([[Media:RodinWorkshop2021_OntoEventB.pdf|pdf]], [[Media:RodinWorkshop2021_OntoEventB_slides.pdf|slides]])
# There is exactly one bound for a model where the probabilistic convergence is proved. The Bound element B shall be of the same type as the declared variant.
+
* EVBT — an Event-B tool for code generation and documentation - ''Fredrik Öhrström'' ([[Media:RodinWorkshop2021_EVBT.pdf|pdf]], [[Media:RodinWorkshop2021_EVBT_slides.pdf|slides]])
# Every probabilistic event shall be refined by a probabilistic event.
+
* Scenario Checker: An Event-B tool for validating abstract models - ''Colin Snook, Thai Son Hoang, Asieh Salehi Fathabadi, Dana Dghaym, Michael Butler'' ([[Media:RodinWorkshop2021_Scenario Checker.pdf|pdf]], [[Media:RodinWorkshop2021_Scenario Checker_slides.pdf|slides]])
# The result of merging a probabilistic event and a convergent event is a probabilistic event.
 
  
We can face two types of situations during the static checking:
+
'''10:30 - 11:00''' ''Break''
# We encounter a problem which doesn't affect the PO generation: it leads to a '''warning''' (fixed by a default assumption or not).
 
# We encounter a problem which affects the PO generation: it leads to an '''error''' (The element, added with our extension and under consideration, is not added in the statically checked model).
 
  
We have previously said that there is two types of modules. We first define a <tt>processorModule</tt>. Processor modules literally process the elements, storing them once validated in the statically checked file.  
+
'''11:00--12:30'''
In parallel, a <tt>filterModule</tt>s performs only some verifications (i.e. a <tt>filtermodule</tt> cannot do anything with the statically checked file). Furthermore, the filters are called (in group) from processors, and as soon as one filter rejects one element (i.e. "does not accept the element"), the other filters will not be evaluated for this element.  
+
* Context instantiation plug-in: a new approach to genericity in Rodin - ''Guillaume Verdier, Laurent Voisin'' ([[Media:RodinWorkshop2021_Context instantiation plug-in.pdf|pdf]], [[Media:RodinWorkshop2021_Context instantiation plug-in_slides.pdf|slides]])
 +
* Examples of using the Instantiation Plug-in - ''Dominique Cansell, Jean-Raymond Abrial'' ([[Media:RodinWorkshop2021_Examples of using the Instantiation Plug-in.pdf|pdf]], [[MEDIA:RodinWorkshop2021_Examples of using the Instantiation Plug-in_slides.pdf|slides]])
 +
* Data-types definitions: Use of Theory and Context instantiations Plugins - ''Peter Riviere, Yamine Ait-Ameur, and Neeraj Kumar Singh'' ([[Media:RodinWorkshop2021_Data-types_definitions.pdf|pdf]], [[Media:RodinWorkshop2021_Data-types_definitions_slides.pdf|slides]])
 +
* Towards CamilleX 3.0 - ''Thai Son Hoang, Colin Snook, Asieh Salehi Fathabadi, Dana Dghaym, Michael Butler'' ([[Media:RodinWorkshop2021_Towards CamilleX 3.0.pdf|pdf]], [[Media:RodinWorkshop2021_Towards CamilleX 3.0_slides.pdf|slides]])
  
In a <tt>processorModule</tt>, if the static check fails for the considered element, the module '''must not add such element''' to the statically checked file that it holds, and which is used for PO generation. Processors are also responsible of running sub-processors, and filters, as well as adding states to the repository if required.<br>
+
'''12:30--13:30''' ''Lunch''
The developer is responsible of its module configuration lifecycle. He has to be aware, at any time, of his module's hierarchy, and has to call sub-modules explicitly when meaningful. Furthermore, a system of state sharing (via a state repository) is available so that a processor can provide informations about its checking results to its sub-modules. See <tt>org.eventb.core.sc.state.ISCStateRepository</tt> and <tt>org.eventb.core.sc.state.ISCState</tt>. Remember that it is only allowed to share informations within a module/sub-module hierarchy and that a policy should be established so that concurrent access to these states is taken into account, and that informations stored in the state repository are still coherent through sub-processors and filters computations.<br>
 
  
Three methods can be used (e.g. overridden) in a <tt>processorModule</tt>:
+
'''13:30--15:00'''
* <tt>void initModule(IRodinElement element, ISCStateRepository repository, IProgressMonitor monitor) throws CoreException</tt>, which by default does nothing, but should be used in order to initialise the state (e.g. information) sharing.
+
* Keynote: Safety and Security Case Study Experiences with Event-B and Rodin - ''Jonathan Hammond, Capgemini Engineering'' ([[Media:RodinWorkshop2021_Safety and Security Case Study Experiences with Event-B and Rodin.pdf|slides]])
* <tt>void process(IRodinElement element, IInternalElement target, ISCStateRepository repository, IProgressMonitor monitor) throws CoreException</tt>, which MUST be implemented to perform static checking.
+
* Large Scale Biological Models in Rodin - ''Usman Sanwal, Thai Son Hoang, Luigia Petre, and Ion Petre'' ([[Media:RodinWorkshop2021_Large Scale Biological Models in Rodin.pdf|pdf]], [[Media:RodinWorkshop2021_Large Scale Biological Models in Rodin_slides.pdf|slides]])
* <tt>void endModule(IRodinElement element, ISCStateRepository repository, IProgressMonitor monitor) throws CoreException</tt>, which by default does nothing, but should be used if <tt>initModule()</tt> was used, to release the states locally created.<br>
+
* Formal Verification of EULYNX Models Using Event-B and RODIN - ''Abdul Rasheeq, Shubhangi Salunkhe'' ([[Media:RodinWorkshop2021_Formal Verification of EULYNX Models Using Event-B and RODIN.pdf|pdf]], [[MEDIA:RodinWorkshop2021_Formal Verification of EULYNX Models Using Event-B and RODIN_slides.pdf|slides]])
  
==== Adding a processor module ====
+
=== Organisers ===
The processor that we will create will perform checks, and eventually add the statically checked version of the Bound element to the statically checked machine. As we don't really need to share information to our sub-modules, only the <tt>process()</tt> method will be overridden.
+
<p>Chair: Asieh Salehi Fathabadi, University of Southampton, UK</p>
 
+
<p>Co-chair: Thai Son Hoang, University of Southampton, UK</p>
For the extension point <tt>org.eventb.core.scModuleTypes</tt> create an extension <tt>processorType</tt>.<br>
+
<p>Co-chair: Colin Snook, University of Southampton, UK</p>
1. Enter a unique ID (like here <tt>machineBoundModule</tt>).<br>
+
<p>Co-chair: Yamine Ait Ameur, Toulouse National Polytechnique Institute, France</p>
2. Enter a human readable name such as "Machine SC Bound Module" as we will start to check bound elements.<br>
 
3. Enter the parent ID of the module we want to extend. Here as we want to make checks on bounds, variants and events, we will take <tt>org.eventb.core.machineModule</tt> as parent.<br>
 
4. Create the module class that <tt>extends SCProcessorModule</tt> (we called it "MachineBoundModule" and we used the "new class wizard").
 
 
 
The module class we created has to be implemented.<br>
 
Two methods inherited from the interface <tt>ISCProcessorModule</tt> have to be defined (e.g. <tt>@Override</tt>):
 
 
 
''A . <tt>public IModuleType<?> getModuleType()</tt>''
 
 
 
This method shall return the type of our module, built from its extension's ID. In order to do that, we use the static method in <tt>org.eventb.core.sc.SCCore.getModuleType()</tt> with the complete identifier of our module extension: <tt>QualProbPlugin.PLUGIN_ID + ".machineBoundModule"</tt>.<br>
 
Thus, let's use the constant below in our code:
 
 
 
public static final IModuleType<MachineBoundModule> MODULE_TYPE = SCCore.getModuleType(QualProbPlugin.PLUGIN_ID + ".machineBoundModule");
 
 
 
So we can write:
 
 
 
@Override
 
public IModuleType<?> getModuleType() {
 
return MODULE_TYPE;
 
}
 
 
 
''B . <tt>public void process(IRodinElement element, IInternalElement target, ISCStateRepository repository, IProgressMonitor monitor) throws CoreException</tt>''
 
 
 
This method is the place where checks are performed. Thus, it is where we will code all the conditions to check and finally produce a statically checked Bound element if all the conditions are respected.
 
The implementation is "huge" and pure Java, and it is not relevant in this tutorial to detail the full code. We will rather explain which are the main operations performed by the <tt>process</tt> method and give some hints about how to use the Rodin API to retrieve the information required in our checks. Full implementation is let to the reader as an exercise.
 
 
 
Here are some explanations about the <tt>process()</tt> method arguments:
 
 
 
The <tt>element</tt> passed as argument here is the element propagated by the parent of this module. It may be useful in case of systematic element checking, to retrieve the elements to check in a parent processor module, and then manage each element one by one, calling sub-processor modules.<br>
 
The <tt>IInternalElement</tt> target is the statically checked file where our elements, after successful well-formedness verification, will be stored. This file will be used as an input for the PO generation.<br>
 
The parameter <tt>ISCStateRepository</tt> repository is the global repository used by the module to get shared information. (//FIXME complete the static checker page, to add infos about states and link it here).<br>
 
Finally, <tt>IProgressMonitor</tt> monitor is the progress monitor used while performing the static checks. Sub-tasks can be created for it.
 
 
 
In our case, we have to refine the well-formedness conditions into a verification algorithm. We choose to retrieve the bound and variant values from the machine root directly using the following code in the <tt>process</tt> method:
 
 
 
final IRodinFile machineFile = (IRodinFile) element;
 
final IMachineRoot machineRoot = (IMachineRoot) machineFile.getRoot();
 
final IBound[] bounds = machineRoot.getChildrenOfType(IBound.ELEMENT_TYPE);
 
final IVariant[] variants = machineRoot.getVariants();
 
 
 
Warnings and errors will be created using the method <tt>createProblemMarker</tt> (see <tt>org.eventb.core.sc.SCModule</tt>).
 
 
 
==== Exercise 1 - Implement the proposed algorithm (among others) ====
 
 
 
If the machine does not contain a probabilistic event, but there is a bound,
 
then we add a warning informing that the bound is ignored.
 
 
If the machine contains at least a probabilistic event (i.e. "the model is probabilistic"), but there are more than one bound,
 
then we create an error telling that there are too many bounds, nothing is created an we return immediately.
 
 
// We are now sure that there a single bound
 
If the model is probabilistic
 
   
 
    If the variant is not a set or a constant, we create an error and return.
 
      The following code may serve as a basis:
 
 
      private boolean assertIsASetOrConstant(IExpressionElement element)
 
throws RodinDBException {
 
              final String formula = element.getExpressionString();
 
              final IParseResult result = factory.parseExpression(formula, LanguageVersion.V2, element);
 
              final Expression boundExpression = result.getParsedExpression();
 
              return isASetOrConstant(boundExpression.getType());
 
 
          with
 
 
              private boolean isASetOrConstant(Type type) {
 
if (type.equals(factory.makeIntegerType())) {
 
return true;
 
}
 
final Type baseType = type.getBaseType();
 
if (baseType != null) {
 
return type.equals(factory.makePowerSetType(baseType));
 
}
 
return false;
 
}
 
   
 
    If there is no bound, we create an error, and return.
 
 
    If the bound is not a set or a constant, we create an error, and return.
 
 
    If the bound is not of the same type as the variant, we create an error and return.
 
      One may check it as follows:
 
                        if (!getType(bound).equals(getType(variant))) {
 
createProblemMarker(bound,
 
EventBAttributes.EXPRESSION_ATTRIBUTE,
 
ProbabilisticGraphProblem.VariantBoundTypeError);
 
return;
 
}
 
    [...]
 
 
 
// After all checks, we add the bound to the statically checked file.
 
final ISCBound scBound = target.getInternalElement(ISCBound.ELEMENT_TYPE, BOUND_NAME_PREFIX);
 
scBound.create(null, monitor);
 
scBound.setExpression(getExpression(bound), null);
 
 
 
In the processor module, one may use the filters to drop a part of the processing with the invocation <tt>filterModules(element, repository, monitor)</tt> which will return a boolean telling if the element has successfully passed all the filtering criteria or not.
 
One may also process an element using the child processor modules with the following invocation:<br>
 
<tt>protected final void processModules(IRodinElement element, IInternalElement target, ISCStateRepository repository, IProgressMonitor monitor) throws CoreException</tt>
 
 
 
==== Exercise 2 ====
 
We use here a filter <tt>machineBoundFreeIdentsModule</tt> to check that the expression of the ''Bound'' element parses, and that no additional free identifier was introduced.
 
Implement such a filter using the fact that the repository holds a type environment which contains all the usable free identifiers. To use this, we have to add a ''prereq'' clause to our filter pointing the ID <tt>org.eventb.core.machineVariantModule</tt> of the variant module.
 
Here is an extract of the filter's <tt>accept()</tt> method:
 
 
 
final ITypeEnvironment typeEnv = repository.getTypeEnvironment();
 
final Expression parsedExpression = parseResult.getParsedExpression();
 
 
final FreeIdentifier[] freeIdentifiers = parsedExpression
 
.getFreeIdentifiers();
 
 
boolean ok = true;
 
for (FreeIdentifier ident : freeIdentifiers) {
 
if (!typeEnv.contains(ident.getName()))
 
createProblemMarker(bound,
 
EventBAttributes.EXPRESSION_ATTRIBUTE,
 
ProbabilisticGraphProblem.BoundFreeIdentifierError,
 
ident);
 
ok = false;
 
}
 
return ok;
 
 
 
=== Step 3: Setting up the configuration ===
 
 
 
In order to register our checks, and because these verifications may be separated in several modules, we need to encapsulate them into a configuration.<br>
 
The extension point <tt>org.eventb.core.configurations</tt> allows to do that.<br>
 
To organise our modules:<br>
 
1. Create an extension <tt>configuration</tt> from the above mentioned extension point.
 
:Give it an ID (for example "qpConfig").
 
:Give it a human readable name (for example, "Qualitative Probabilistic Reasoning Plug-in SC Configuration").
 
 
 
2. Add the modules (full id) previously defined to the configuration. In our example, we implemented two modules:<br>
 
- <tt>fr.systerel.rodinextension.sample.machineBoundModule</tt><br>
 
- <tt>fr.systerel.rodinextension.sample.machineBoundFreeIdentsModule</tt><br>
 
 
 
That's all for configuration creation. Now, we need to add it to machine file configurations so it can run when our plug-in is installed.
 
 
 
=== Step 4: Adding the configuration ===
 
 
 
The best way to add our configuration is to register a utility class that will add our configuration to the machine files when our plug-in is active, and if their configuration doesn't contain ours.
 
To do so, create the following class that implements <tt>org.rodinp.core.IElementChangedListener</tt>:
 
 
 
/**
 
  * Class that updates the configuration of files, to add the static checker
 
  * modules for our qualitative probabilistic reasoning plug-in.
 
  */
 
public class ConfSettor implements IElementChangedListener {
 
 
private static final String QUAL_PROB_CONFIG = QualProbPlugin.PLUGIN_ID
 
+ ".qpConfig";
 
 
public void elementChanged(ElementChangedEvent event) {
 
 
final IRodinElementDelta d = event.getDelta();
 
try {
 
processDelta(d);
 
} catch (final RodinDBException e) {
 
// TODO add exception log
 
}
 
}
 
 
private void processDelta(final IRodinElementDelta d)
 
throws RodinDBException {
 
final IRodinElement e = d.getElement();
 
 
final IElementType<? extends IRodinElement> elementType = e
 
.getElementType();
 
if (elementType.equals(IRodinDB.ELEMENT_TYPE)
 
|| elementType.equals(IRodinProject.ELEMENT_TYPE)) {
 
for (final IRodinElementDelta de : d.getAffectedChildren()) {
 
processDelta(de);
 
}
 
} else if (elementType.equals(IRodinFile.ELEMENT_TYPE)) {
 
final IInternalElement root = ((IRodinFile) e).getRoot();
 
 
if (root.getElementType().equals(IMachineRoot.ELEMENT_TYPE)) {
 
final IMachineRoot mch = (IMachineRoot) root;
 
final String conf = mch.getConfiguration();
 
if (!conf.contains(QUAL_PROB_CONFIG)) {
 
mch.setConfiguration(conf + ";" + QUAL_PROB_CONFIG, null);
 
}
 
}
 
}
 
}
 
}
 
 
 
Where the string constant ''QUAL_PROB_CONFIG'' refers to our configuration in the machine files. We check that each manipulated machine file contains our configuration.
 
Now we need to launch this class at plug-in start-up.
 
 
 
To do so:<br>
 
1. Open the activator of our plug-in.<br>
 
2. Add a method <tt>setProbConfig()</tt> to the <tt>start(BundleContext context)</tt> method of the activator.<br>
 
3. Implement this method:<br>
 
        /**
 
* Registers a file configuration setter for our plugin.
 
*/
 
public static void setProbConfig() {
 
RodinCore.addElementChangedListener(new ConfSettor());
 
}
 
 
 
 
 
{{Navigation|Previous= [[Extending_the_Static_Checker(How_to_extend_Rodin_Tutorial)]] | Up= [[Plug-in_Tutorial|How to extend Rodin Tutorial (Index)]] | Next= }}
 
 
 
[[Category:Developer documentation|*Index]]
 
[[Category:Rodin Platform|*Index]]
 
[[Category:Tutorial|*Index]]
 

Revision as of 15:17, 15 June 2021

9th Rodin User and Developer Workshop

The 9th Rodin User and Developer Workshop, 8 June, 2021, Ulm, Germany (Virtual)

The proceedings of the workshop is now available as a [technical report] at the University of Southampton.

The programme now available on the ABZ2021 website and below (with texts).

Event-B is a formal method for system-level modelling and analysis. The Rodin Platform is an Eclipse-based toolset for Event-B that provides effective support for modelling and automated proof. The platform is open source and is further extendable with plug-ins. A range of plug-ins have already been developed.

The 9th Rodin workshop will be collocated with the ABZ 2021 Conference.

The purpose of this workshop is to bring together existing and potential users and developers of the Rodin toolset and to foster a broader community of Rodin users and developers.

For Rodin users the workshop will provide an opportunity to share tool experiences and to gain an understanding of on-going tool developments. For plug-in developers the workshop will provide an opportunity to showcase their tools and to achieve better coordination of tool development effort.


Programme

09:00 - 10:30

  • Domain knowledge as Ontology-based Event-B Theories - I. Mendil, Y. Aït-Ameur, N. K. Singh, D. Méry, and P. Palanque (pdf, slides)
  • OntoEventB: A Generator of Event-B contexts from Ontologies - Idir Ait-Sadoune (pdf, slides)
  • EVBT — an Event-B tool for code generation and documentation - Fredrik Öhrström (pdf, slides)
  • Scenario Checker: An Event-B tool for validating abstract models - Colin Snook, Thai Son Hoang, Asieh Salehi Fathabadi, Dana Dghaym, Michael Butler (pdf, slides)

10:30 - 11:00 Break

11:00--12:30

  • Context instantiation plug-in: a new approach to genericity in Rodin - Guillaume Verdier, Laurent Voisin (pdf, slides)
  • Examples of using the Instantiation Plug-in - Dominique Cansell, Jean-Raymond Abrial (pdf, slides)
  • Data-types definitions: Use of Theory and Context instantiations Plugins - Peter Riviere, Yamine Ait-Ameur, and Neeraj Kumar Singh (pdf, slides)
  • Towards CamilleX 3.0 - Thai Son Hoang, Colin Snook, Asieh Salehi Fathabadi, Dana Dghaym, Michael Butler (pdf, slides)

12:30--13:30 Lunch

13:30--15:00

  • Keynote: Safety and Security Case Study Experiences with Event-B and Rodin - Jonathan Hammond, Capgemini Engineering (slides)
  • Large Scale Biological Models in Rodin - Usman Sanwal, Thai Son Hoang, Luigia Petre, and Ion Petre (pdf, slides)
  • Formal Verification of EULYNX Models Using Event-B and RODIN - Abdul Rasheeq, Shubhangi Salunkhe (pdf, slides)

Organisers

Chair: Asieh Salehi Fathabadi, University of Southampton, UK

Co-chair: Thai Son Hoang, University of Southampton, UK

Co-chair: Colin Snook, University of Southampton, UK

Co-chair: Yamine Ait Ameur, Toulouse National Polytechnique Institute, France