sics-sse / moped

Mobile Open Platform for Experimental Development

moped

Mobile Open Platform for Experimental Development of Cyber-Physical Systems

This project contains source code, developed in a research project on software architecture for Cyber-Physical Systems (CPS), https://moped.sics.se/. It is primarily intended for use in research and education environments.

The code is intended to operate on a hardware platform based on an RC car, equipped with a distributed control system, consisting of a number of Raspberry Pi (RPi) boards. The goal is to simulate typical behavior of an automotive electronic system, while providing the means for them to be easily upgradable with new (plugin) software and allowing them to interact with each other and other embedded systems.

It consists of the following packages:

• Autosar OS port to Raspberry Pi hardware, incl. necessary drivers for the MOPED platform
• Plugin server code, which in its turn consists of a plugin manager, used for managing plugin configuration and distribution; and a web portal php-code
• External Communication Manager (ECM) code, running on a Linux node on the MOPED platform and communicating with the external world (for example to receive plugin binaries from the central server)
• Squawk java virtual machine port to Autosar OS and Raspberry Pi hardware
• PlugIn RunTime Environment (PIRTE) code, running on Autosar nodes on the MOPED platform, and providing dynamic runtime properties to the Autosar software (such as installation and uninstallation of new software and communication services for dynamically installed plugins)
• Simulator, intended to simplify plugin development off-board
• WirelessIno, an Android app for RC car steering using a smart phone
• Plugin repository
• API for the plugin developer
• Some useful tools

To get started:

• Read everything in the "doc" directory.
• Building is done by running server/misc/buildall.sh

Forum for discussion of the MOPED platform: http://mopedforum.prophpbb.com

Repository: https://github.com/sics-sse/moped

moped's Issues

New structure for Application table in DB

Ersätt DatabasePlugin, VehiclePlugin, PluginPortConfig, PluginLinkConfig, PluginConfig, AppConfig med Application-tabell + xml-fil.

Application tabellen ska ha följande kolumner:

• id
• description
• name
• version (på format x.y.z (osv), som hämtas direkt från pom.xml)
• publisher (hämtas direkt från den inloggade Wordpress-användaren)
• date (datum för uppladdning)
• mainClass
• status (uploaded / compiled / tested / published)

Utifrån namn och version ska man kunna räkna ut placeringen av jar-, xml-, och suite-filer.

Inspirationsexempel på hur en xml-fil kan se ut finns på ~/plugins/SemiAutomaticReverseParking/src/main/resources/SemiAutomaticReverseParking.xml

I ett senare skede vore det bra att justera xml-strukturen (men det är ett annat issue).

Write pom.xml files for those plugins which don't have them.

moped/plugins/AP, for example.
They are from the time before mvn was used.

Simulator: FakeECUManager needs revisions

The code is very confusing: there is one public method called sendMessage, and a number of other private methods also called sendMessage (but with other parameter types) which are called from the first.

Since these private methods only contain a few lines, they should be refactored to be inlined in the calling method.

Also, the class should be called something else.

Simulator: Check XML files for conformance with XML schemas

When XML files are read, they should be checked for conformance against an XML schema.
This will simplify the code for extracting parts of the XML file greatly, since it will not anymore be necessary to check that the XML has the correct structure.

Primarily, this should be done in CarFactory.generateCar().

http://stackoverflow.com/questions/15732/whats-the-best-way-to-validate-an-xml-file-against-an-xsd-file

Clean up the WebServices interface and make it more modular

Vissa funktioner används inte i WebServices gränssnittet, medan andra gör "allt". De sistnmämnda skulle förmodligen kunna brytas upp i flera logiska enheter.

T.ex. en applikation kan ha statusen uploaded / compiled / tested / published. Varje status skulle kunna motsvaras av en WS-funktion.

För att kunna anropa nästa tjänst i följden måste den tidigare vara genomförd (t.ex. måste en applikation vara "uploaded" för att kunna kompileras).

Install apps from the remote control

Add functionality in the Android remote control app to mirror some of
the wordpress functions: installing apps, for example.
Idea by Jakob.

Let simulator create Vehicle-instances

Låt simulatorn skapa bilinstanser, givet vissa kända VehicleConfig, och radera dem när simulatorn stängs ner. De borde dock inte behöva lagras i databasen.

Code coverage

Investigate code coverage of Java, to see if we missed something important when running test cases.
(and php and any other kind of language we are using)

Move from using .zip-files to .jar-files

Det innebär inga större ändringar. Redan idag skapar vi först en .jar-fil som vi sedan döper om till .zip (utan att ändra innehållet), allt för att de existerande funktionerna ska fortsätta fungera. Men man måste gräva lite i de funktioner som sköter nedladdningen av filer till bilen och simulatorn (lite pill kan det ändå bli).

Error handling and reporting

A place to put references to specific issues related to error handling.
Take care of all return values.
See #24
Catch exceptions.
Ideally, tell the user exactly where in a complex chain things went wrong and why.
Format nicely on the web page.
Write to syslog or log4j or equivalent, not only on stdout.

Simulator: Remove CarFactory class

Move the parts for creating a car from an XML file to the Car class.

Simulator: WriteLED declared as sensor

In the config/system1.xml file, writeLED is declared as a sensor, should be an actuator. (Is this info used anywhere?)

Remove vehicleConfig in User_Vehicle_Association

Send xml/jar-files directly through WebService-calls

Idag laddas filerna först till ett temporärt ställe och sedan kopieras de vidare till deras slutdestination. Detta gör att man inte bara kan ta och använda samma WebService för att ladda upp filer från t.ex. en Eclipse-plugin.

Model car: LEDs are turned on at startup

LEDs are turned on at startup, and it is unclear if 0 or 1 should be used to turn them on.

Clean up VehicleConfig table; Remove Ecu, Port, and Link tables

Ersätt tabellerna Ecu, Port och Link med en xml-fil som beskriver en bilkonfiguration.

VehicleConfig-tabellen ska då ha följande kolumner:

• name
• version
• description
• configFile

Konfigurationsfilen i sin tur ska innehålla info om vilka ECU-er som är definierade för denna bilkonfiguration (helst med namn istf id). Vidare ska varje ECU ha en uppsättning portar (Ports), som beskriver det API som pluginutvecklarna har tillgång till. Varje ECU har också ett antal länkar (Links), som beskriver kopplingar mellan typ-II-portar på olika ECU:er. (I nästa steg borde det räcka med att lägga in länk-informationen i port-taggen, t.ex. som recieving port, med det tar vi i ett annat issue).

Exempel på hur en config xml-fil ser ut idag finns på ~/simulator/configs/system1.xml. Det kan kanske vara bra att ha som utgångspunkt.

Clean up the Git

There are a number of files that should be deleted and added to .gitignore

Make Squawk invocation direct

Today, Squawk is invoked via a shell script (d.sh), which in its turn calls appropriate .jar libraries. They should be called directly from java.

This will also allow to clean up on the server and only keep Squawk's .jar-files there.

Java version

Update the java version to 1.8 on the server (otherwise plugins won't compile to .suite).

Another alternative is to compile Squawk and plugins with 1.7, but that seems as a step backwards.

Make plugins independent of Squawk version

Today, a simple change in Squawk (such as a print-out) makes it necessary to recompile all plugins.

Restructure the Vehicle table

Vehicle-tabellen ska ha följande fält:

• name
• description
• vin
• applications (installed apps)

VIN (vehicle id number) ska hämtas utifrån WiFi-MAC-adressen för t.ex. en RaspberryPi. Om det är simulatorn som anropar servern så kan den hitta datorns WiFi-MAC-adress, med ett eventuellt tillägg (sträng) för att skilja på olika bilar i simulatorn.

Simulator: Remove ECU and SWC classes

The ECU class is never really used (instances are created in CarFactory but are thrown away).
The SWC class is just a container for a PIRTE.

Refactor Pirte API

Currently the API is located in 3 places: Squawk, Simulator, and as a freestanding api. It should have a unique core, referenced and possibly overriden by the other projects.

Simulator: CarFactory.clearECUFiles() doesn't do anything

Either fix this, if necessary, or remove the method.

Document how to build the system

Document how to build the system from scratch, starting from cloning from
github. Includes how to test things along the way to see if it works.

Separate Wordpress DB and Fresta DB

• wpdb passar logiskt sett till att hantera Wordpress-sidor
• Fresta DB sköter all annan logik och anropas via WebServices, antingen från en php-fil (t.ex. Wordpress) eller t.ex. direkt från Eclipse.

All funktionalitet borde göras via WebServices, medan WP-sidan blir så lättviktig som möjligt.

Make file paths and network addresses and ports configurable, where appropriate

For example, where the simulator finds the server, and where the server finds the database, etc.

Server: App file changes name when installed or downloaded from server

If the compiled app is called app-1.0.jar, the file that gets installed from the server is called app.zip. It would be more logical if it had the same name as the original file.

ECM-Core: CarDriver hard codes port 9000

General: Set up Maven poms

Maven pom needed for overall project, in particular dependency between ecm-core, simulator, ecm-linux, plugins, etc.

Create InstalledApplication table

En ny tabell behövs för att hålla reda på vilka appar som har blivit installerade var. Den ska ha:

• id
• vehicleId
• applicationId
• status (pending / installed / inactive)

Warnings when building

Give heed to warnings when building (from javac and other tools)
Either change the code to make them go away, or if that's not
possible, disable them.

Ask vehicle what it actually has installed on it

Provide a way to find out what is actually installed in a car by asking it. Web service, probably.

Allow several active vehicles

Ändra defaultVehicle till selectedVehicle i User_Vehicle_Association.

Eller... det kanske är ännu bättre att ha ett fält som heter "active" i Vehicle, så kan man låta User_Vehicle_Association göra precis det som namnet antyder, d.v.s. kopplingen mellan användaren och bilen (och inget annat).

Simulator: In CarFactory.generateCar(), sensors and PIRTE ports not treated

When reading in the parts of the XML file relating to PIRTE ports and sensors, not actions are taken. Why?

DB objects stay in memory

It seems as if direct (manual) deletion of some DB rows (such as PluginPortConfig) doesn't work. They seem to be deleted, but Hibernate still finds them (or is it about query caching).

Add authentication to the server web services

Use the wordpress wp_users table, which uses the 'phpass' hashing algorithm.

Create SQL schema

Create an SQL schema file that describes how all tables for the trusted server should be created, e.g. containing rows such as:
"create table Vehicle (id integer, name string, description string, vin string)"

Use this file when the trusted server binaries are launched to create tables unless they already exist.

Also, use the same schema file to create temporary SQLite DBs in junit tests.

ECM-Core: ECM.start() hard codes what ECUs exist in the system

When loading apps upon startup, the start() method explicitly loads apps into ECU2 and ECU3, instead of actually looking which ECUs exist in the system.

Mvn-artefact

Create a maven artefact that creates a shell plugin-module (e.g. incl. simulator-dependencies)

Better structure for vehicle configuration files

Strukturen på xml-filer som beskriver hur en bil är konfigurerad skulle må bra av en uppdatering.

Det är flera saker jag tänker på (och det kan finnas fler):

• Portarna borde ha namn
• Sensor- och aktuatortaggarna borde användas (de är också portar)
• Portar skulle kunna behöva typ-tag (I, II eller III). Kanske?
• hasPirte-taggen känns onödig, vi behöver väl inte deklarera Ecu:er som inte har Pirte.
• link-taggar borde kunna rymmas som en post under port-taggar (det är egentligen bara -infon som är intressant om man gör det på det viset).
• name, brand och vin borde kunna ersättas med ett enda fält, t.ex. name.
• Vet inte om -infon behöver vara där eller om just den borde vara hårdkodad.

Let vehicles "pull" communication with the trusted server

Idag är det istället servern som pushar ut data till bilarna. Man kan tänka sig att användaren sätter en flagga (via Wordpress-gränssnitt) om att vissa appar ska installeras. Nästa gång bilen startar upp så får den fråga servern om det finns något att installera och sedan begära installation.

Simulator: Show LEDs in simulator

In the simulator GUI, add elements showing the status of the LED:s in the car.

Server: Issues with port assignment for apps

Ports should be unique per car, not unique globally.

Testing

A place to put references to specific issues related to testing.
Idea: when unit testing an app, let the tester code start an instance of the simulator, and insert the app into it, without involving the server.

Simulator: Not possible to have several cars

Many of the fields describing the state of a vehicle in the simulator class CarModel are declared as static. This will cause problems if several cars are instantiated simultaneously in the simulator. There are other issues as well with having multiple cars in the simulator, such as reading the configuration file, controlling them with the remote control, etc.

It also seems that the RTE can only exist in one instance (the class method getInstance() is called from the generateCar() method in CarFactory).

Success-printout even in case of failures

This happens for example when uploading or uploading+compiling a plugin

SOAP between server and vehicle

Make the communication between the server and the car use SOAP.
#36 should probably be done first or at the same time.

Create an API.jar

Create an API that can be used as a maven dependency when compiling plugins (instead of relating to simulator.jar or squawk.jars).

Add this dependency to our moped artifact, so that it is filled in when a new plugin maven module is created.

Debugging tools

for Java, php, etc.