Next Steps
Improving Sensor Management for Users
One of the things we would like to improve on is administrator control. Right now, once an administrator has signed up to the website, the only thing he is able to do is add new sensors. Features we would like to include in the future include:
- Editing existing sensors
- Deleting existing sensors
- Editing account settings
- Sorting list of sensors
- Alerts for when parking bays have exceeded the allowed maximum stay
Some of these things are quite simple to add, but we decided to push them out of our current scope, as they are unnecessary features. Right now we can manually edit sensors behind the scene and edit account settings, so they were not required to present the use of our system.
Support for TCP connections
Right now, our system only accepts UDP connections. We chose UDP, because it was simpler to implement with our chosen hardware, but TCP has some advantages over UDP. Although the rate at which data can be received is lower for TCP, the chance the data will get there is far higher. It is in-fact pretty much guaranteed. If you refer to our testing section on UDP, if we send 1000 packets per second, we lose about 5%. In a small scale system like ours, this is not something to worry about, but on an industrial scale, it can be very worrying.
Usability Improvements for the Smart Parking Application
Right now, the smart parking app is already very usable. It will show you on the map exactly where and when parking bays are available. It will even tell you what the nearest available one is. Although there is of0course always room for improvement. Here is a list of future goals for the app:
These features are not necessary for the launch of the app, but would make the app more user friendly and practical. We want to take it from simply showing you the bays to actually guiding you to them and alert you when you are close to staying for too long.
Reassessing our noSQL database
For this project to become viable in the larger scale, our cassandra database would most likely need remodelling. Currently it is fully functional, but it is not as efficient as it could be. When dealing with small datasets, this is not a problem, as the difference in efficiency is not noticeable. However if we are to store thousands or millions of strings of data, accessing them all as quickly as possible starts to become important.
- Plans or ideas we have for expanding the prototype
- Associated notes on how to go about it
- Links to issues identified in 'testing and evaluation'
- Maybe something about client feedback..?
Future Goals
Looking into Hadoop
Now that we have a system running that stores sensor data at a decently large scale, the next step would be to perform more complicated analytics. With a large enough set of data on specific parking bays, we would be able to perform analytics through hadoop for things like what time of the day the parking bays are most occupied or least occupied.
Native API Expansion into other popular languages
Right now we have 2 APIs for accessing data on the database, a Java API and a RESTful API. In the future, it would be nice to create more ways to access this data depending on your preferred type of programming language. We want our developers to be able to use our data as easily as possible, so adding more way in which they can do that would definitely be a future goal.
Migration to Cassandra for the Smart Parking application
Currently we are storing data for the Smart Parking app on a SQL database. This works fine if all we are doing is display the data, but if we want our app to perform more complex analytics and display this analysed data, then moving to a noSQL database like Cassandra would be advised.
Get Involved
We're constantly evolving and looking into how we can better ourselves. If you have skills or interest in the areas of Big Data, networking, or sensor hardware, you're well-placed to play a founding role in the early stages of this project.
What's up next?
Everything detailed above in 'next steps' is our primary focus. Largely they're quite straight-forward developments, so you may be more interested in 'future goals'. These outline more clearly the larger steps we want to make from where we are now to where the project could be in a year or so. If they're the kind of thing you have experience in, read on for details on helping us out.
How to help
First and foremost, it's important to us that you stay in the loop. It's best to use our forums for this - we'll be posting regular updates and keeping you alert for any open positions on the team
If you're interested in more details on how to make a start writing code for us, or for applications using the data, have a good look at the implementation details or the manuals for the APIs.