Version: 1.0 Project spec released
In Task 2 you wrote a simple network simulator to allow the fat controller to interact with Thomas and his friends.
The simulator had a function to set the lights on the fat controller's panel (so she could work out the location of the trains (to some extent)), and a function to set the signals and points on the network.
The Project is to implement the fat controller. Or rather, the brains of the fat controller - via the function Strategy.ai().
To be more precise - you will write a function, ai(), which, given some data about the network and given the state of all the lights immediately before a tick, determines the best way of setting the points and signals to "optimally" control the trains for the next few ticks.
"Optimally" means to maximise the profit of the network whilst ensuring complete safety.
The "profit of the network" we define to be the profit of the least profitable train. In this project we do not include running costs when determining train profit.
"Ensuring complete safety" means that networks which have an accident, or which from the point of view of the fat controller might have an accident save for events beyond her control, have a profit of negative infinity.
We will provide a top level wrapper module, FatController.hs, which will repeatedly call your functions, to allow you to:
Unless otherwise stated the network structure, definitions, and assumptions are the same as for Task2.
Labour 1 is a joint effort by the entire tutorial in week 8, the remaining labours are done by your group (pair).
Design the interfaces for the types Location and Strategy.
We *require* some functions to be in the interfaces (see labour 2 below) but you will most probably need to add some more in your design.
To come up with a good interface design you should think carefully about what you need to write the required interface functions.
The design is to be a joint effort by your entire tutorial class in the week 8 and 9 tutorial and lab. Everyone in the tutorial must comply with the agreed interface specification.
Prepare for this carefully in advance. Participate in the design process in the tutorial. You do NOT want to end up with a flawed or overly difficult interface.
Your tutorial's interface will then be published by the week 8 tutorial presenter/s.
Any subsequent changes to the published interface for your tutorial must be agreed to by a 2/3 majority of tutorial members. This is most unlikely to happen, so make sure you get it right the first time.
You are required to implement the Location and Strategy types and the functions required by our FatController module (2 per module - these are listed below).
You must also implement any other functions your tutorial decides to put in the interfaces for the Location and Strategy ADTs.
Each type is to be defined in a module named after itself (ie Location.hs & Strategy.hs).
The two types are to be abstract. Thus:
Create a variable of type Location, to record the possible location(s) of trains in the network
Create a variable of type Strategy, to represent the brains of the fat controller, and to determine her strategy for maximising profit/safety.
-- *Will be called each time one (or more) light(s) go(es) on -- *may be called at other times -- *might not be called in the initial state of the network -- even if lights are on in this state -- -- Each button will have been in the state specified by -- ControlStatus for the entire period since the trains left -- the locations they were in in the input (ie previous) -- Location
-- Return a list of commands to update the controls on the -- network based on their current location (the input -- Location data reflects the current location of the trains). -- -- The list should contain at most one command per control. -- -- The ai should seek to "optimally" control the trains -- as defined in the spec. -- -- In deciding your strategy you may assume that this function -- will be called immediately after each call to updateLocation. -- This is so that it will be able to respond to future events -- as they occur. --
makeLocation and makeStrategy are permitted to take a minute or so to run (we'll run them before starting the simulation). ai and updateLocation should be faster since they are run during the simulation. (I'll post some timing data but the limit will only be a few seconds on a lab machine,)
In addition to your interface functions you may write any other helper functions you require. In addition to the Location and Strategy modules you may write (and submit) any other helper modules you require.
Your modules may not import the Network module. If you really need to make use of its interface functions then copy it into a module with a different name (which you also submit), and import that. It is extremely unlikely you will need to do this.
Write implementations of the remaining 3 Network interface functions, and alter the behaviour of Network.getProfit() to ignore running costs (we will not count running costs in the project).
-- there is an accident if -- two trains are ever on the same track or cross the -- same track junction during the same tick (collision), -- OR -- a train enters a fork track on the To segment which -- is not connected to the From segment, -- OR -- a command to change state is ever issued to a fork track -- while a train is on it, -- OR -- a command to change state and stop trains is ever issued -- to a simple track while a train is on it. -- -- the first two types of accidents happen during a tick, -- the other types occur between ticks - when the command -- is issued. -- -- this function returns True if and only if (iff) the -- network has ever had an accident. This includes any -- accidents generated by an immediately prior call to -- sendCommands. -- -- whenever an accident occurs append an Accident -- safety Message to the list of messages.
-- True if controls cannot be used to prevent a future accident -- with 100% certainty -- -- to be precise: -- -- if, in the current state of the network, there exists some -- finite sequence of future speeds (in the range 0..4) for -- trains in the network at the end of which, regardless of -- which Strategy.ai function is used, isAccident() will be -- True. -- -- note - this is under the assumptions for the project. In -- particular note the project assumption about how often the -- ai() function is guaranteed to be called. -- -- Notice that the isUnsafe status of the network may -- fluctuate and even if it is True at some stage, it might -- return to False at a later stage (as the actual speeds -- experienced might not be worst case speeds). This differs -- from the behaviour of isAccident(). -- -- If the system is unsafe at the instant a nextTick() -- function is called append an Unsafe message to the list -- of messages.
-- return the network's current list of safety messages -- (initially empty)
The functions isAccident(), getMessages(), and getTicks() are the only Network functions whose behaviour is defined after an accident.
We will be awarding two sets of bonus marks for the project:
We'll run a competition in the last few weeks of session and see how much proft your fat controller can make compared to everyone else's. Performance marks will be awarded on a sliding scale depending on how your fat controller goes. Competition bonus marks for the top 25% of teams also.
If your ai() and updateLocation() functions are fast enough you will be able to let your code control the real plastic train/lego robot testbed. We may run a lego based round of the competition for such fast entries, and award some of the bonus marks based on the results.
"Fast enough" will depend on the setup of the testbed. It will probably be a limit of less than about 0.5-1.0 seconds in total to run both functions back to back.
As well as the core marks for detecting unsafe situations we'll see if your team's isUnsafe() function can detect a series of increasingly more cunningly disguised unsafe networks. Bonus marks awarded on a sliding scale depending on how many you can detect.
Notice that the safety definition for the isUnsafe() function differs from the "Ensuring complete safety" definition above. In particular isUnsafe() might regard as safe a situation which, from the point of view of the Fat Controller, is not safe.
Download the library file ThomasLib.hs. You may not alter this file. Import it in your module to access the shared types used in task 2 and the project.
Assumptions you may make about the assignment.
Note these files have changed since task2 so download fresh copies. Check back from time to time to ensure you have the latest copies.
[an error occurred while processing this directive]
Update History
1.0: 5-5-03
Spec released.
Minor wording changes
and clarifications. No
running costs in computation of
profit. Indicitive speed limits
to be eligible for physical
simulation reduced.
0.3: 1-5-03
two cases added to definition
of an accident, minor wording
changes.
0.2: 28-4-03
minor alterations,
safety functions explained,
types for updateLocation
altered, reference to
updated ThomasLib.hs, time
limits on ai and updateLocation
set to "a few seconds"
0.1: 26-4-03
preliminary version