I'll address the question title first: the difference between a daemon and a normal running process is that most times when you say "normal process" you mean something that is connected to a user input/output API, such as a text terminal (usually by having its first 3 file descriptors in the file descriptor table opened and connected to a virtual terminal of some sort), or a graphic user interface (on Linux and UNIX usually using the X11 protocol). A daemon on the other hand often refers to a process that has been detached from a terminal, or was never attached to one in the first place.
As to the question itself, both when running as a daemon, or when running as a "normal process", an application might crash and will need to be restarted. When the process is connected to some user terminal, a user can detect the fault and restart the application, but a daemon usually doesn't enjoy that feature - when the daemon disconnects from a terminal, it makes it much more difficult to detect that the process has crashed.
To solve this problem, we invented service management frameworks. There are many different implementations, with different features: SysV, SystemD, Upstart, Supervisord, runit, and many others. They all share a very important feature: they have some way to start a daemon (often automatically on boot) monitor it until it fails, and then start it again.
Should you use a service management framework to run your device driver service? You most definitely should - it is the only sane way.
Which service management software to use, is a more difficult question. Usually, the best choice is to use whatever service management software your operating system bundles - usually this software is also running as process ID 0 and started directly by the kernel. Currently, the most prominent such software in modern Linux based operating systems is SystemD which offers a lot of features such as rich dependency management language, socket activation, timers, network and storage management and more. AFAIK, in embedded Linux operating systems this is not often the case and likely your embedded system uses classic SysV which isn't very good at restarting failed services (or often doesn't do that at all - it leaves that task to the "service script" and most implementations do not perform any kind of restart). With a SysV based operating systems, a lot of administrators prefer to use the SysV service framework to just start another service manager - such as supervisord or runit - and let that manage their services.