V1.0 Requirements discussion

[PBrunot]

I'm opening an issue to gather feedback regarding requirements identified for the RFID lab machine management. I use English as the end-goal may be to integrate such a solution in Fab Manager.

Requirements for V1.0 (can be revised):

Functional requirements

• Board must enable usage of lab machines by users, based on individual RFID tags
• Board must be easy to use with no user training requirements (usage in a school context)
• Board must be robust in case of WiFi issues, to avoid blocking the lab or powering off machines it network is out of service
• Board must be low-maintenance for Fab Lab (ideally only initial setup and no batteries)
• Board must physically fit next to the machines
• Board must not interfere with long jobs (e.g. printing large 3D pieces)
• Cumulative hours Machine usage must be registered for maintenance
• Board must signal that machine maintenance is needed (e.g. laser lens cleaning every X hours)
• A FabLab user can register maintenance operations to reset the maintenance signal
• Server must be able to handle several boards simultaneously (min. 10 boards)
• A FabLab admin must be able to ENABLE/DISABLE machine for general usage
• Server must provide statistics per machine (usage log, hours cumulated, maintenance done)

Regulatory requiments

• GDPR compliance based on fab member consent or anomized data.
• Boards must be electrically safe for usage in public space.

Economical requirements

• Boards must be low cost to manufacture (criteria < 50 eur/board)
• Server must be low cost to operate (criteria < 50 eur/year)

Excluded requirements for V1.0 (can be revised)

• Access control (boards control machines, not doors).
• Server shall not depend on Fab Manager (this can be done later, and it requires some plugin because the FabManager data model is not ready : no hours per machine, no maintenance, no attribute for users to link to tags, non-Fab users in the lab...)
• Server shall not handle users abilitation to machines (this feature can come with the Fab Manager integration)
• Board shall not track consumables (e.g. meters of filament acquisition)
• Board shall not track actual machine running time (it will rely on user log-on and log-off)

Design choices so far

• Board must control power of the machine (230Vac) or provide a volt-free contact (e.g. EN signal to machine board)
• To avoid user interaction on board, one machine per board is supported.
• Basic architecture (Machine) <-1-connected to-1-> (Board) <-n-connected-to-1-> (Server)
• Board has microprocessor, 16x2 LCD, RFID reader, buzzer, WiFi and bluetooth connection.

[valerionew]

Thanks Pascal, looks good!

I can add a few points, mostly from a staff member perspective:

• Maintenance performed checks should be performed by a staff member before the user is allowed to use the machine. This could conflict with the board controlling machine power, as power may be required for maintenance (e.g. mirror align on laser cutters, moving the CNC axes for cleaning etc.). I'm thinking of asking for a staff member's card to activate the machine for maintenance. We could add the option to postpone maintenance, but should we really? I'm thinking of a short tap with a staff member's card to postpone by a power cycle vs a hold for three seconds for start maintenance.
• We don't strictly need to get the system on printed circuit boards that are manufactured. We could do with a kit made of commercial modules, at least for the first version of the system (the one that we will deploy at first).

Also, where should we put the requirements for the server? Here there is a first old draft of the specs: https://github.com/fablab-bergamo/rfid-database-interface/blob/main/README.md

Here there is also a rough TODO list: https://github.com/fablab-bergamo/rfid-database-interface/blob/main/TODO.md

[PBrunot]

@valerionew : I've added the maintenance performed to the boards (it's in the open PR #3 ). When the machine requires maintenance, usage is blocked. A short tap from a fablab admin will enable the machine anyways (so postponing maintenance is not required). A long tap (3s) will register the maintenance operation as done.

Regarding PCB: most of the standard parts are in the lab, no problem. What is your idea for machine connection ? I'm not sure we can do safely interrupt a powerline with standard parts on a breadboard... I'm not an EE engineer, but it would required case-assembly-soldering of parts-fixtures before we connect mains wires ?... Also, I think the lab machines do not have an "external enable" signal to bring a volt-free signal from the relay. Maybe we could add in serie the relay to a safety interlock.

Finally regarding server requirements I have opened a separate issue in fablab-bergamo/rfid-database .

[valerionew]

Probably breaking the interlock chain is the safest, I agree with you. But while the lasers and CNCs have that, there is no interlock in 3D printers. One strategy would be operating the reset pin of the control boards, but that is not always obvious to find and to "hack into", plus it requires some modifications to the board itself that can invalidate warranty.

My idea was indeed to interrupt the power line. In 3D printers we could safely and easily do it on the low voltage line. So the user would still have to turn on the machine via the usual switch, and then the box would prompt the user for a card, closing the low voltage circuit.

Another discussion we have to do is powering of our system. If we intercept any power, such as in 3D printers, we can exploit that. But if we don't, like with the lasers and the CNCs, how do we power the box?

Last big thing on this point, we should forecast the possibility of a system that we cannot modify at all (even with non-permanent modifications). In that case, the only option would be to interrupt the power cable.

[valerionew]

@PBrunot If it is ok with you, I would like to give you write access to this repo, so you can work directly on a branch of this repo instead of a fork.

[valerionew]

I've also created a project in the organization's page to help us keep track of the various ongoing feature developments.

I don't know if this is going to be useful, if not just leave it be and we will delete it.

Projects documentation on github

[PBrunot]

Nice, I've never used projects but it looks like a better option than using issues to keep tracks of things to do. I've created a few tasks in it.

[PBrunot]

Review of Requirements as of June 2024

Functional requirements

Requirement	Status	notes
Board must enable usage of lab machines by users, based on individual RFID tags	✅	-
Board must be easy to use with no user training requirements (usage in a school context)	✅	QRCode and LCD
Board must be robust in case of WiFi issues, to avoid blocking the lab or powering off machines it network is out of service	✅	Caching of RFID+whitelist to allow usage
Board must be low-maintenance for Fab Lab (ideally only initial setup and no batteries)	✅	Powered by the machine itself
Board must physically fit next to the machines	✅	approx 10x10x6 cm
Board must not interfere with long jobs (e.g. printing large 3D pieces)	✅	Autologoff can be disabled
Cumulative hours Machine usage must be registered for maintenance	❌	Some bugs to be fixed
Board must signal that machine maintenance is needed (e.g. laser lens cleaning every X hours)	✅	LCD displays expired maintenance text
A FabLab user can register maintenance operations to reset the maintenance signal	✅	Done with long tap
Server must be able to handle several boards simultaneously (min. 10 boards)	✅	Tested with 5,6 so far without issues
A FabLab admin must be able to ENABLE/DISABLE machine for general usage	✅	"Blocked for all" in backend project
Server must provide statistics per machine (usage log, hours cumulated, maintenance done)	✅	See backend project

Regulatory requiments

Requirement	Status	notes
GDPR compliance based on fab member consent or anomized data.	❌	Purge and GDPR consent to be reviewed
Boards must be electrically safe for usage in public space.	✅	So far only 24VDC is used

Economical requirements

Requirement	Status	notes
Boards must be low cost to manufacture (criteria < 50 eur/board)	✅	approx 15eur/board
Server must be low cost to operate (criteria < 50 eur/year)	✅	runs on Raspberry Pi or DebianVM

Excluded requirements for V1.0 (can be revised)

Requirement	Status
Access control (boards control machines, not doors).	❌ not planned
Server shall not depend on Fab Manager (this can be done later, and it requires some plugin because the FabManager data model is not ready : no hours per machine, no maintenance, no attribute for users to link to tags, non-Fab users in the lab...)	not started
Server shall not handle users abilitation to machines (this feature can come with the Fab Manager integration)	✅ actually this has been done in the backend as optional step for critical machines
Board shall not track consumables (e.g. meters of filament acquisition)	❌ not planned
Board shall not track actual machine running time (it will rely on user log-on and log-off)	💡could be done with external signal