Hi there (from Hungary),
I'm about to finish my studies as an electrical engineer bsc at summer and looking forward to write my thesis related to implement some embedded application. The main idea behind it to learn some valid and sustainable technology. My interests are embedded linux and C++ and developing CI/CD systems with Docker for the scope of this project.
The exact application would be an access control system for my university to limit and monitor the entrances of teachers', students', other employees etc to different zones of the building. For the time being, the notion is not so clear how exactly it will be carried out but here are the main requirements:
- Wireless communication when authenticating/authorizing with RFID or NFC, and on success opening/closing a door/gate etc.
- Encryption. (I am not an expert on this one, really. I just know that a system like this is unimaginable without solutions against attacks. :) )
- The node devices (hardware next to doors to open them) to be able to communicate in a peer-to-peer manner for the purpose of updating each others configuration/database containing user information and be able to function autonomously.
- An application with a web UI running on a PC for administrators to arbitraily adding/modifying/removing users, grant custom permissions which user has access to which zone of the building. (I am planning on implementing this with Java as I have an experience of 1.5 years in building web apps with it.)
So as I said my main interest are Linux and getting some programming skills in C++ (and Docker) and I am trying to avoid native microcontroller programming, but I am afraid that the choosen tech stack is way too much determined by my own (selfish) intentions of learning the desired tools ingoring the facts like:
- The cost of a system like this - with 30-40-50 devices - raises too high because of choosing strong enough hardwares being able to run an embedded linux OS with contenarized applications.
- Ignoring real-time constraints needed by an application like this. (I too am not an expert on this one. :D)
So the overall question: is it overkill or worth the efforts? Maybe I should look for another application if I'm insisting on linux/C++ etc.?
Thx for the answers in advance!
The best solution would be:
1. An 8 bit controller base end devices with a small scheduler to do the job of event based communication to a gateway through wireless modules which uses serial interface.
2. A gateway of a low end 32 bit controller, here it is not a must to use Linux, however if you are so much passionate you can use Raspberry pi running Linux, and
3. A PC based unit which will communicate to gateway through Ethernet, which can be completely Linux based.
The complexity of the task is quite a bit, and I would advise you to make a judicial choice of low end systems to avoid as much programming to make the required functionality being achieved there, (but requires at least some percentage of programming to suit complete end to end system functionality).
The gateway and the PC based system you have to spend > 70% of efforts to make the system work.
Hope this will give you an indication of split of efforts.
Also be clear about the scope so that you can do it and successfully demonstrate to the academia. It is better to put a simple functional system with 2 devices, 1 gateway and build it from bottom up approach.
All the best.
You've got "Don't use Linux", "Do use Linux", and "Use a mix" -- so, at this point, you can do what you want without fear.
If I were going to build a system like this as a commercial product I'd figure about a 12-16 month development time from product inception to completion, with two to four each of mechanical, electrical, and software engineers. That's assuming an absolutely basic product that doesn't include anything but exactly one style of door unit, no options to the UI, one door unlocker, one way of wiring them up (I'm guessing you want PoE, but that's just a wild guess), and a PC as a central unit. For something that'd compete with what you could buy on the open market (at least in the US) you'd probably need twice that -- and that's just the engineering personnel, not the installation and repair people.
Then I'd expect at least a six-month teething period that needs to be supported by about half the team, and finally an ongoing product support phase that'd require one of each for the life of the product. So you may wish to recruit a team. Or consider doing a demonstration project, and leave it to someone else to actually implement it.
I priced out boards, and came up with $5 each for a Raspberry Pi Zero, which will do the job if you run Ethernet and power everywhere, $10 each for a Raspberry Pi Zero W, which has wireless Ethernet so you just need power everywhere, and the ittiest-bittiest Arduino at $10 each, for which you'll have to custom-write communications programs and communicate with some other sort of "big" computer to boot.
There is absolutely nothing in your requirements that demands an RTOS, or that rules out Linux. There's absolutely nothing in there that demands Linux, but just about all of the features that you mention will be easier to implement on a Linux machine -- and the Raspberry Pi Zero and Zero W are Linux machines (although you have to be really sparing with what you put in them -- you certainly won't be running Doom). So if you're looking at actually saving money going with Linux hardware.
("But I want to roll my own hardware!" No you don't -- not for something at this sort of production volume. If you do insist, then recruit someone to do nothing but copy the Raspberry Pi's circuit onto a board of your choosing, possibly with the ID reader on the same board. It's the "big company" way of doing it, but it'll cost you at least a man-year.)
I'd look to see if there's a suitable RFID or card-swipe reader that can be hooked up to the Raspberry Pi Zero, and if so, run with that. I'm assuming that the Pi Zero has a serial port, so the field should be wide open. If you can get to the point where you have half a dozen door units, with no housings, on a table, all talking on Ethernet to a central PC for authorization, then I'd say you'd done a really good job for one individual. If you can recruit at least one mechanical engineering student to design and print some housings, then you'll have something visually appealing, as well.
With a son of mine currently in college, I have to ask: since when do universities worry about costs? :-)
Silliness aside, it can be very tempting to specify the platform based on the technologies we want to work with. I would recommend to avoid such an approach to product design. As an engineer, or future engineer, the requirements of the project should be the primary driving force of the design, not the microcontroller or SoC or language we want to work with. Of course, everything should be within reason too!
Given the limited description, perhaps two devices may be in order:
* sensor/endpoint devices. Limited capabilities. Maybe something like FreeRTOS with appropriate communication stacks. I certainly have no qualms recommending C++11 for this code.
* Hubs/routers: Linux based devices. Devices to help route new data and extend the reach of all the sensors/endpoints. Likely Linux/C++ combo based device.
* PC/Web: as noted in the description already. Python. Java. C#. etc. etc. Personally would target C#.
So keep gathering requirements. Especially, who is paying for it and what is their budget? That may very well force decisions... budgets tend to do that!
This seems to be an interesting project. I would use distributed intelligence deploying multiple microcontrollers at various levels. Each access device deploys an mcu and a WiFi module. A typical combo would be RENESAS Synergy S1 MCU with an ESP32 module. L these devices can communicate with a PC based system to do the rest of the processing.
For access devices, going for a Linux based embedded system such as ARTIK 520 may be a good choice.
If the communication interface of the RFID reader is a UART, you can use that to communicate with Linux.
if you not allreaddy found the 'FAQ posts' have a look at the first message in
one that i think is a good inspiration for parts of your questions is
Selecting the Right Microcontroller for your Application
and i will write some things that come to my mind here - also i never have done a project like this and are more of a prototype 'creative' guy than 'planing carefully for mass-production' ;-) ...
First - i don't know exactly what your part is in this hole thing...
so do you have to write only about a concept that could theoretically work?
or do you have to build a prototype to proof a concept and in this step also to show what does not work as planed?
or do you have to develop and build a finally working product/implementation for you university?
for the rest of my writing i assume that you have to build a prototype showing the concepts work and after this - redesign/iterate on this to be able to run a mini production-run (as you mentioned ~50 devices).
So first - if it is designed for production runs with ~50 devices it makes a lot of sense to use of-the-shelf modules for complex parts like RFID...
same for the software stack! - if you are not familiar with some uC stack that gives you all of the basics you need - but are familiar with (embedded) linux -
there are a big bunch of different vendors out there that have a good level of different System on Modules that can run Linux and free you partly from the 'low-level-stuff' - and they are not really pricier than doing it yourself at this quantities..
just a few that are coming to my mind immediately:
they all give you some 'quick-start' options with using an evaluation-board...
that is great for building a first proof-of-concept prototype to test basic ideas (hardware and software..)
then i would search for an 'diy' / hobby RFID/NFC breakout-board with good library / language and example support - (i have once worked with the one available from adafruit in combination with an rpi and python for some interactive exhibits) - be prepared to read a bunch of basic information regarding the RFID/NFC technology... for me it was 'surprisingly' complex..
i personally would go for a ethernet based communication between the nodes- and on top of this would include POE to power them- this makes the installation very easy as someone (external) can just install a network socket at the target positions - and somewhere a POE-enabled Network Switch...
with this you also can add a ups(uninterrupted power supply) backup to the switch and are done with this ;-)
the network gives you all freedoms how the nodes interactive with each other (if its a distributed system or if there is a central server that updates every node...)
if you work with modules at the hw level its also easier as you don't need to know/engineer every detail like RF or highspeed processor/memory connections and such.. you basically can design your own special base-board that holds/incorporates whats needed to get the SoM to working.
i was a bit surprised as i watched the video by mikeselectricstuff that teared down a commercial unit that used a similar concept:
in the big picture it stays a big and complex project ;-)
(things like remote software upgrades are to be considered)
one thing i also would give a good thought is the documentation/maintenance part -
how easy is it to add new functionality for someone new - as eventually this project gets picked up by someone else later...
i think its a interesting idea and real-live usable application.
have fun and let us know how it goes ;-)
Not an ad, but search an MDEK1001 keyword. This is very new product that is not widely known yet. The system like you have described almostly done and can be used with not a lot of knowlege required. You also can customize your user IoT functionality in a user thread. It also has a Pi connection, that actually you can run parts of that system in a standalone and in a host modes.