Skip to content

Homework part 1 ‐ Graph Modeling

Jump to bottom
Ármin Zavada edited this page Oct 20, 2024 · 21 revisions

Overview

The goal of this homework is to get familiarized with graph-based modeling and metamodeling. In this task we will provide a modeling environment for complex Cyber–physical systems, which enables us to model

  • a network of collaborating computers
  • with their software and hardware communication
  • including sensors and controllers.

In the homework, we will use the control system of a smart home with:

  • sensors measuring the temperature and controlling the heating
  • cameras detecting movement and controlling the lighting with the help of an object-detection AI.
  • We are operating a smoke detector hard-wired to an alarm.
  • We are implementing the system with 3 small computers and a PC operating as a server.

Development environment

For the development of the metamodel, we will use the Refinery graph generator framework. The initial project is available here: https://github.com/ftsrg-edu/ase-labs/tree/hw1 . To start the homework, copy and paste the contents of the specified branch into your homework repository or clone your repository and execute the following commands inside it:

git remote add ase-labs https://github.com/ftsrg-edu/ase-labs.git
git fetch ase-labs
git switch hw1
git push -u origin

During this task, we need to do two things:

  • We need to develop a metamodel, which is available in the file hw1.problem (available here). Please change this file only. For the development, we can use the online editor of the tool available at ▷Refinery or run a server for yourself (not necessary). Please submit a syntactically correct solution!
  • We need to run the tests to see if we are progressing well. The tests are available here. (The tests will be executed during the scoring of the task as well.)

The initial version of the cps.problem partitioned into two parts:

  • The first part contains the empty declaration of the metamodel. Currently, this part is empty During the homework, we need to change this part. However, all other parts rely upon the node and edge labels introduced here, so please do not change the names!
  • The second part is introduced with the following message: % % Please do not modify anything below this line. Do not delete this line!. After this, the problem file specifies the closed-world assumptions and an example instance model of a smart home. At every stage, we can check our progress by adding back the closed-world and instance model specifications to the modeling environment. The full specification of the smart home model is available here in Annex 2.

Tasks

During this task, our goal is to create a metamodel for the smart home modeling environment. As an input, we will get a specification and an example instance model.

The specification will look like this.

% And the example instance model specification will look like this.
CPSModel(model).

Task 1. Simple metamodeling: Software repository

  • In the first stage, we will have step-by-step instructions for the homework. Later stages will be more creative.
  • First, we will create the metamodel related to Software and Hardware repositories. For this part, our specification is the following:
    • Each model consists of a single CPSModel, which will be the root element of the containment hierarchy of all objects in the document.
    • The CPSModel may contain multiple different software types (SoftwareType) organized in a software repository (softwareRepository).
    • A software type (SoftwareType) describes a software in the market. Each software might be purchased and installed multiple times: those are called software instances.
    • Each software type may depend on multiple other software, which can be denoted by the dependsOnSpecificSoftware reference.
  • For each stage, we need to use the signature highlighted in the specification. In this example, we used CPSModel and SoftwareType as unary predicates, and softwareRepository and dependsOnSpecificSoftware as binary predicates. If we miss to use those predicates, the test framework will identify that as an error. The full list of the signatures is listed in Annex 1.
  • For the first task, we will give a reference solution, which may look like this:
class CPSModel {
    contains SoftwareType[] softwareRepository
}
class SoftwareType {
    SoftwareType[] dependsOnSpecificSoftware
}
  • At the current stage, we can try to add the first part of the instance model to the end of the document (either by removing the comment or inserting the following code):
% Stage 1.

% Close world assumption 1.
!exists(CPSModel::new).
!exists(SoftwareType::new).
default !softwareRepository(*,*).
default !dependsOnSpecificSoftware(*,*).

% Instance model 1.
CPSModel(model).
/**
    There are two kinds of Operating Systems in the repository.
*/
softwareRepository(model,raspberryPiOS).
softwareRepository(model,fedoraLinux).
/**
    There are multiple image processing softwares.
*/
softwareRepository(model,yolov8).
softwareRepository(model,yolov10).
softwareRepository(model,openCV).
dependsOnSpecificSoftware(yolov8,fedoraLinux).
dependsOnSpecificSoftware(yolov10,fedoraLinux).
dependsOnSpecificSoftware(openCV,fedoraLinux).
/**
    There is a java-based control panel system, that works everywhere.
*/
softwareRepository(model,openHAB).

  • At the current stage, there should not be any syntactic or semantic error in the model.

  • If everything goes well, the visualization should show the following graph:

    Graph illustration first stage

Task 2. Hardware configuration

  • At this stage, we will add computers to the specification:

    • The CPSModel may contain multiple different computer types in the form of a computer repository (computerRepository).
    • A computer type (ComputerType) describes a computer (hardware) in the market.
    • Each hardware can have multiple instances.
    • A computer instance (ComputerInstance) denotes the copy of a hardware.
    • Each instance can be configured in a different way.
    • The computerType relation connects the instances with the types.

  • Moreover, we can define cyber-physical system design as a collection of computers.

    • The CPSModel may consist of multiple different CPS designs.
    • A CPS describes a configuration of computers (which are computer instances).

  • At the current stage, we can define the CPS model of our smart home design with the following code:

% Stage 2.

% Close world assumption 2.
!exists(ComputerType::new).
!exists(ComputerInstance::new).
default !computerType(*,*).

/**
    There are multiple versions of raspberry computers.
    The PC describes a generic desktop computer; no details are
    added at the current stage.
*/
computerRepository(model,raspberryPi3).
computerRepository(model,raspberryPi4).
computerRepository(model,raspberryPi5).
computerRepository(model,raspberryPi5).
computerRepository(model,pc).

/**
    myHome is the CPS system of the intelligent house
*/
designs(model,myHome).

/**
    Everything is controlled by a central pc computer called server.
*/
computers(myHome, server).
computerType(server,pc).

/**
    There are two computers with cameras and light controllers.
*/
computers(myHome, cam1Computer).
computerType(cam1Computer,raspberryPi5).
computers(myHome, cam2Computer).
computerType(cam2Computer,raspberryPi5).

/**
    There is a temperature controller responsible for heating.
*/
computers(myHome, temperatureController).
computerType(temperatureController,raspberryPi5).

  • At the current stage, there should be no errors, and the visualization should look like this:

    Graph illustration second stage

  • If there are additional dashed edges, it denotes that the containment references might be missing.

Task 3. Software configuration

  • Let us specify the software installation on each computer.

A software instance (SoftwareInstance) denotes the copy of software type (SoftwareType) installed on a computer. Each software instance may have different configurations and licenses. The softwareType relation connects the instances with the types. Each computer may have some installed software instances (installedSoftwares).

  • At the current stage, we can enable the modeling of the software configuration of the smart home configuration.
% Stage 3.

% Close world assumption 3.
!exists(SoftwareInstance::new).
default !softwareType(*,*).
default !installedSoftwares(*,*).

% Instance model 3.

installedSoftwares(server,imageProcessing).
softwareType(imageProcessing,yolov8).
installedSoftwares(server,serverOS).
softwareType(serverOS,fedoraLinux).

installedSoftwares(cam1Computer, cam1OS).
softwareType(cam1OS,raspberryPiOS).

installedSoftwares(cam2Computer, cam2OS).
softwareType(cam2OS,raspberryPiOS).

installedSoftwares(temperatureController, temperatureOS).
softwareType(temperatureOS,raspberryPiOS).
  • There should be no errors, and the visualization should look like this: Graph illustration third stage

Stage 4. Hardware configuration.

  • Next, we can define the special hardware that our CPS modeling environment needs.

    • A Hardware describes a piece of extra equipment for computers (like sensors, controllers, or special video cards). There can be Sensor and Controller hardware, among others. For example, a Camera, Thermometer, and SmokeDetector are sensors, while HeatController, LightController, and FireAlarm are controllers.
    • A VideoCard is a special kind of hardware, which is neither a sensor nor a controller.

  • Those special equipment can be added to the model.

    Each computer instance may contain some extra hardware (extraHardware), but not more than 3.

  • At this stage, we can assign the different hardware to the computers. The following hardware configuration should compile:

% Stage 4.

% Close world assumption 4.
!exists(Camera::new).
!exists(Thermometer::new).
!exists(SmokeDetector::new).
!exists(HeatController::new).
!exists(LightController::new).
!exists(FireAlarm::new).
!exists(VideoCard::new).

default !extraHardware(*,*).

% Instance model 4.

extraHardware(server,nvidiaCard).
VideoCard(nvidiaCard).
extraHardware(server, fireAlarm).
FireAlarm(fireAlarm).

extraHardware(cam1Computer,camera1).
Camera(camera1).
extraHardware(cam1Computer,light1).
LightController(light1).
extraHardware(cam1Computer,thermometer1).
Thermometer(thermometer1).

extraHardware(cam2Computer,camera2).
Camera(camera2).
extraHardware(cam2Computer,light2).
LightController(light2).
extraHardware(cam2Computer,thermometer2).
Thermometer(thermometer2).

extraHardware(temperatureController,heatController).
HeatController(heatController).
extraHardware(temperatureController,smokeDetector).
SmokeDetector(smokeDetector).

  • Then, the visualization should look like this:

    Graph illustration third stage

Stage 5. Communication architecture.

  • Finally, we can define the communication network between the computers.

    • Each computer can communicate with others. Communication must be mutual.
    • A specialty of the FireAlarm is that it has a direct connection to at least a single SmokeDetector via a directSensorConnection. Similarly, a SmokeDetector is connected back to the FireAlarm via the directAlarmConnection reference. In each case, there must be at least a single connection.

  • At that stage, we can add the connections.

% Stage 5.

% Close world assumption 5.
default !directSensorConnection(*,*).
default !directAlarmConnection(*,*).
default !communicatesWith(*,*).

% Instance model 5.
/**
    In the network, every computer communicates with the server.
*/
communicatesWith(server, cam1Computer).
communicatesWith(cam1Computer, server).
communicatesWith(server, cam2Computer).
communicatesWith(cam2Computer, server).
communicatesWith(server, temperatureController).
communicatesWith(temperatureController, server).

/**
    Additionally, there is a direct link between the alarm
    and the smoke detector.
*/
directSensorConnection(fireAlarm,smokeDetector).
directAlarmConnection(smokeDetector,fireAlarm).

  • At that stage, the visualization looks like this:

    Graph illustration of the smart home system.

Stage 6. Additional Hardware

  • Please extend the metamodel with at least 3 extra hardware types and 2 extra relations.
  • Make sure that you do not change the other parts of the metamodel so the original instance model still conforms to it.

Annex 1: List of types and relations.

In this homework, please use the following names of the concepts so the tests can check the correctness of your solution.

Camera communicatesWith ComputerInstance computerRepository computers ComputerType computerType Controller CPS CPSModel dependsOnSpecificSoftware designs directAlarmConnection directSensorConnection extraHardware FireAlarm Hardware HeatController installedSoftwares LightController Sensor SmokeDetector SoftwareInstance softwareRepository SoftwareType softwareType Thermometer VideoCard

Annex 2: Description of the instance model.

The smart home specification used in the running example introduces several concepts and relations:

  • First, it introduces a repository of possible computers that can be used. There are multiple versions of Raspbery Pi computers, and a PC describes a generic desktop computer.
  • There are multiple image processing software including Yolo and OpenCV.
  • myHome is the CPS system of the intelligent house.
  • Everything is controlled by a central pc computer called server.
  • There are two computers with cameras and light controllers.
  • There is a temperature controller responsible for heating.
  • In the network, every computer communicates with the server.
  • Additionally, there is a direct link between the alarm and the smoke detector.

A visualization of the smart-home environment is illustrated below.

Graph illustration of the smart home system.

Background materials

Clone this wiki locally