ftsrg/bme-modes3

Model-based Demonstrator for Smart and Safe Systems

bme-modes3's Issues

Refactor IMessageDispatcher

The interface is not capable of registering message handlers yet. If anyone in the future would implement a new data transfer format, then this part will have to be refactored accordingly.

Related issue #38

Implement central logging

Define communication messages

Programmed train control

Provide support for programmatic control of both the trains and the turnouts. As we discussed before in person, the task should cover the following steps:

• Define the operations for the trains an the turnouts
• Implement a "dispatcher" application that is able to execute commands on the table
• Create a java jar and C library for application developers
• Extract the parameters of the communication to a configuration file (e.g. topic passwords, broker IP, etc...)

Missing DCC parts

• connecting one rail to DCC (one side of the table already done)
• PC Interface mounting and connection

Testing the communication layer

Create unit tests and add comments for the BBB code

Find a permanent place for the demonstrator

Design turnout control expander header

Modify the Arduino C++ code so that it transfers the section occupancy vector through UART instead of MQTT.

Missing safety boxes for 230VAC connections

Upper layer refactor

Clean up interfaces for the state machines of the safety logic

Create platform model instance, application model and deployment (allocation) model

Design circuit for enabling and disabling sections

DCC-PC interface based train control

• Test the PC interface on the new board
• Create a tightly coupled C++ based MQTT/Protobuf stack
• Implement command/state features
• Test the communication between this and other components

Restructure and collect requirements based on FURPS

Create high-level requirements for the complete system, but elaborate the requirements only for certain aspects.

Implement web-based MoDeS3 controller

• Upload boilerplate
• Create static view
• Make the page capable of displaying the status of the demonstrator
• Make the page capable of controlling the demonstrator's hardware components

Assign tasks for the members of the project

Add an extra AND gate to circuits mentioned in #15 and #16 for monitor-based intervention purposes

Initiate implementation of a small example project for transforming MagicDraw models

Implement section occupancy query component

So far this component was deployed on Arduino as a C++ code. It communicated with the network through MQTT. The objective was to query the section occupancies through RJ45 ('telephone cable') using S88 protocol and transfer this information (sections occupancy vector) through the network.

Main questions regarding this issue:

1. Where is component is going to be deployed? E.g. Arduino, BBB, Raspberry Pi
2. What language is this component going to be implemented in? C++, Java, etc.
3. If it is going to be implemented in a language different from C++, then how the S88 protocol is going to be simulated (e.g. shift-register with timers implemented in C++ for Arduino)?
4. Are we going to transfer the whole occupancy vector for the network or each section's occupancy will be transferred separately?

asdasdas

• elso reszfeladat
• masodik reszfeladat

Integration of the safety system designed in yakindu

• create proto messages for the inter-statechart communication (between the BBBs)
• integrate the generated Yakindu codes with the (communication) software stack
• write unit tests for the statecharts
• write integration tests for the statecharts and its integration with the software stack

Create data model in MagicDraw for messages to poll the status of the system

New metamodel for the live model of the system level monitor

Implement logging for BBB

Implement logging for section enable/disable, turnout status info query and section status info query submodules. These are in the code package for BBB, because BBB is capable of querying and setting the physical status.

Raspberry Pi 3 power/network wiring

• Raspberry Pi 3 Ethernet connection
• Raspberry Pi 3 5VDC connection

Create live model metamodel in MagicDraw

Missing segment electronics parts

• finish wiring of S88
• S88 interpreter device
• wiring all turnout actuator device to their associated BeagleBone

Find out why VIATRA returns with EObjects instead of the specific types

This could help removing unnecessary casts from the code of the SafetyLogic and its ModelUtil

Communication technologies

Use Google Protobuf for serialization and zeromq for communication

Create physical model in SysML

Document structure of repository

Create a brief description in the readme that describes which component is in which folder in the repository.
Related to #19.

SA/TA PCB manufacturing and assembling

• create BOM (Bill of materials)
• test PCBs
• manage PCB manufacturing

Create a standalone jar of the system level safety logic

So it can be easily deployed to a Raspberry PI or anything with a JRE

Write unit tests for the framework components

Implement logging for safetylogic

Implement Raspberry Pi UART -> ZMQ communication

The byte[] -> ZMQ messages about the sections occupancy is already implemented (related commit e0c7f55). Only the 'how to get the byte[] over UART in Java' part needs to be done.

Add refined stereotypes to SysML bdd

Create stereotypes to express the followings:

• sensing
• actuation
• control
• transport

Update pin allocation

Update the control methods which disable/enable section or set the turnout straight/divergent according to the new pinout headers, as soon as the corresponding PCB’s are manufactured.

Organize repository layout

BME-MoDeS3

• src
  • components
  • messaging
  • transport
• config-management
• docs

Implement logging for CommunicationRegistry

Make a standanlone jar from the BBB section enable/disable code base that would be deployed on the BBBs

Safety system integration

• build with Gradle
• use the new communication API

On/off switch

Also decide its location on the table.

Implement logging for statechart based safetylogic

Turnout control safety check

If the master becomes the responsible unit of the turnout control, a new feature can be added to check the occupation of the turnout before setting it. With this feature, the master can make sure no train is on the turnout in the moment of switching.

Report issue related to mixing Xtend and Java and building with Gradle

Register custom MessageDispatcher

Please make it possible in the hu.bme.mit.inf.modes3.messaging.communication.factory.CommunicationStack class to register a custom dispatcher that implements the IMessageDispatcher interface. In this way we could register message dispatchers for those messages which are not handled by the default ProtobufMessageDispatcher.

The other possible solution would be a Factory which makes it possible to create a CommunicationStack that uses the referred custom dispatcher.