sics-sse / moped Goto Github PK

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.

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

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

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.

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

Ä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).

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.

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)

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

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

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).

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.

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.

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

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

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.

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.

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

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.

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

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.

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.

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

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.

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)

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).

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.

Ports should be unique per car, not unique globally.

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

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.

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

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 functionality in the Android remote control app to mirror some of
the wordpress functions: installing apps, for example.
Idea by Jakob.

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.

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.

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.

for Java, php, etc.

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

• 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.

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).

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.

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

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

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).

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.

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

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.

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