Industrial Controller? Windows or Linux?
12 comments
Hardware (and sourcing) is harder than software. So I would heavily weight which OS is supported for the kind of devices you need, from reliable manufacturers with long support times. Always have multiple sources for the type of hardware used.
You also need to consider who is responsible for monitoring, maintaining and updating the devices OS and software, and whether it is a pull or push type update model. If it is you, then the fact that customers IT department knows Windows is not a benefit (on the contrary, they might cause problems).
When it comes to language and GUI framework, pick based on availability of skills. Having people that know X is more important than what X is. I would try to find a way to solve the modification issue which does not limit your choice of tech. Not being able to use JavaScript/web for UI is a huge limitation wrt access to skills. Tamper protect/detection using cryptography.
You also need to consider who is responsible for monitoring, maintaining and updating the devices OS and software, and whether it is a pull or push type update model. If it is you, then the fact that customers IT department knows Windows is not a benefit (on the contrary, they might cause problems).
When it comes to language and GUI framework, pick based on availability of skills. Having people that know X is more important than what X is. I would try to find a way to solve the modification issue which does not limit your choice of tech. Not being able to use JavaScript/web for UI is a huge limitation wrt access to skills. Tamper protect/detection using cryptography.
If it were me, I would definitely not tie my product's existence to Microsoft licensing.
It seems the most flexible solution is a traditional web stack: Linux for the OS, a backend in whichever language you desire and a web app served to the user (if your product has a display, load the browser in kiosk mode).
It seems the most flexible solution is a traditional web stack: Linux for the OS, a backend in whichever language you desire and a web app served to the user (if your product has a display, load the browser in kiosk mode).
I'm not sure I understand your constraints. Accepting at face value that your app has to be wholly non-user-modifiable, what exactly is wrong with web/JS/Python? Putting a web frontend on the system shouldn't let the user control anything interesting since the frontend is just a client over the real HTTP control interface. And rolling Python in with Java et al., why does it have to be a compiled language? Most users aren't exactly going to pop open the app regardless, and if your threat model includes users patching the program and ex. editing out signature checks, it's not like compiled code will protect you from a debugger/decompiler/hex-editor.
(To answer the actual question as posed: If you can use Linux, I think you'd be crazy to use anything else. It gives you far more control, completely removes the risk of any updates you don't want, can allow really slick update strategies (roll forward/back, snapshots, A/B updates, immutable snapshots...), most likely completely throws out licensing fees for the OS. Like, if your team is familiar with Windows, fine, if you need Windows-specific drivers, sure, but otherwise? It's an appliance; Windows was never a good fit.)
(Edit: Also, whichever OS you go with, please decouple your stuff from the OS as much as possible. If it's Windows, make a real installer or portable app. If it's Linux, it depends on your model (do you control the OS, or do customers?) but make a package/docker image/flatpak/static binary/appimage/self-contained install directory/whatever and document the install process. I say this as someone who has had to come in after something was no longer supported; it's so much easier to update the underlying OS when it's clear how you install the app on a fresh OS image)
(To answer the actual question as posed: If you can use Linux, I think you'd be crazy to use anything else. It gives you far more control, completely removes the risk of any updates you don't want, can allow really slick update strategies (roll forward/back, snapshots, A/B updates, immutable snapshots...), most likely completely throws out licensing fees for the OS. Like, if your team is familiar with Windows, fine, if you need Windows-specific drivers, sure, but otherwise? It's an appliance; Windows was never a good fit.)
(Edit: Also, whichever OS you go with, please decouple your stuff from the OS as much as possible. If it's Windows, make a real installer or portable app. If it's Linux, it depends on your model (do you control the OS, or do customers?) but make a package/docker image/flatpak/static binary/appimage/self-contained install directory/whatever and document the install process. I say this as someone who has had to come in after something was no longer supported; it's so much easier to update the underlying OS when it's clear how you install the app on a fresh OS image)
The hardware and software are delivered as one unit. Think of buying a fancy smart refrigerator. The user doesn't install anything. They turn it on and use it. In this case we'd pre-integrate the rugged tablet with the application and have it launch in single application (kiosk) mode. In other words, from the user's perspective, they turn it on and use it and it isn't a general purpose computer.
While I definitely like the idea of using one of the many Python or JS frameworks for desktop app development, we just can't have the source be openly visible at the moment. It isn't about end users, it's about others.
Yes, I understand, it is impossible to protect against everything. There are a million ways to mess with any system. I get it.
I don't have an adherence to Windows or Linux. Equally comfortable in either environment. I've been using them both since version 1.0.
Part of my thought experiment at this stage is to try to understand what the best decision might be from more than one perspective. Questions such as what UI libraries might be available in each platform. Or, how difficult might it be to hire competent desktop application programmers in each case. Remember, this isn't about building a website. There are millions of very capable web technology coders. That doesn't qualify them to write code that can interface with and control devices in an industrial installation.
Windows has their IoT version which seems to be designed for this sort of application. I need to get in touch with them to discuss. This isn't a high volume application, maybe 1000 units per year. Not sure how that might fit their licensing scheme.
Cost isn't necessarily an issue. If the Qt commercial licensing approach wasn't such a scary mess, I would not have any reservations about paying for that. The problem is that I have to hire an attorney to actually understand it (if I want to be responsible and informed). I have less than zero desire to hire an attorney to choose a development framework.
While I definitely like the idea of using one of the many Python or JS frameworks for desktop app development, we just can't have the source be openly visible at the moment. It isn't about end users, it's about others.
Yes, I understand, it is impossible to protect against everything. There are a million ways to mess with any system. I get it.
I don't have an adherence to Windows or Linux. Equally comfortable in either environment. I've been using them both since version 1.0.
Part of my thought experiment at this stage is to try to understand what the best decision might be from more than one perspective. Questions such as what UI libraries might be available in each platform. Or, how difficult might it be to hire competent desktop application programmers in each case. Remember, this isn't about building a website. There are millions of very capable web technology coders. That doesn't qualify them to write code that can interface with and control devices in an industrial installation.
Windows has their IoT version which seems to be designed for this sort of application. I need to get in touch with them to discuss. This isn't a high volume application, maybe 1000 units per year. Not sure how that might fit their licensing scheme.
Cost isn't necessarily an issue. If the Qt commercial licensing approach wasn't such a scary mess, I would not have any reservations about paying for that. The problem is that I have to hire an attorney to actually understand it (if I want to be responsible and informed). I have less than zero desire to hire an attorney to choose a development framework.
You definitively looking wrong way. You cannot choose software before you have industrial grade hardware.
And sure, you could try to push people to buy non-industrial grade hardware, but I do not advise to go this way.
Industrial grade hardware, is essentially money machine, which is designed to work and gather money, so when for some reason happen out of service, client will suffer money losses.
So reliability is extremely important for this market.
And when you sell system, based on industrial grade components, they usually have in agreement TOS - usually in means of possible unscheduled downtime, for example IBM mainframes have 99.999% uptime (about 5 minutes unscheduled downtime per year, it mean, they will pay money if you will have evidence, that downtime because of their fail).
What this mean, if you have development processes certified for regulations and industrial grade hardware, if something happen, you always will have hard guarantees against sues, but if something is not adequate grade, you could lost huge money.
In some cases, regulations just prohibiting usage of non-certified hardware and software for specific regulated functions (examples are medical equipment, life-critical building management equipment, for example ventilation controller).
And life is complicated. Just few years ago existed huge market niches, where nobody care about non-reliable systems, but last months lot of things changed, now even toys for children are regulated, and I'm not sure when this trend will end.
And you may already understand, exists industrial grade windows, industrial grade linux (even some branch of embedded OS/360), but must say, they are extremely different from "civilian" - for example looks like is is still possible to use industrial OS/2, when civilian is already subject of ancient history, and industrial linux is also probably very old.
Any way, most probably you will not have rights to make significant changes into industrial system (only certified environment, only certified drivers), because if something changed, you will lost TOS guarantees.
Looks like in each case you should carefully check pros and cons of specific system to make decision, what is better for you.
And sure, you could try to push people to buy non-industrial grade hardware, but I do not advise to go this way.
Industrial grade hardware, is essentially money machine, which is designed to work and gather money, so when for some reason happen out of service, client will suffer money losses.
So reliability is extremely important for this market.
And when you sell system, based on industrial grade components, they usually have in agreement TOS - usually in means of possible unscheduled downtime, for example IBM mainframes have 99.999% uptime (about 5 minutes unscheduled downtime per year, it mean, they will pay money if you will have evidence, that downtime because of their fail).
What this mean, if you have development processes certified for regulations and industrial grade hardware, if something happen, you always will have hard guarantees against sues, but if something is not adequate grade, you could lost huge money.
In some cases, regulations just prohibiting usage of non-certified hardware and software for specific regulated functions (examples are medical equipment, life-critical building management equipment, for example ventilation controller).
And life is complicated. Just few years ago existed huge market niches, where nobody care about non-reliable systems, but last months lot of things changed, now even toys for children are regulated, and I'm not sure when this trend will end.
And you may already understand, exists industrial grade windows, industrial grade linux (even some branch of embedded OS/360), but must say, they are extremely different from "civilian" - for example looks like is is still possible to use industrial OS/2, when civilian is already subject of ancient history, and industrial linux is also probably very old.
Any way, most probably you will not have rights to make significant changes into industrial system (only certified environment, only certified drivers), because if something changed, you will lost TOS guarantees.
Looks like in each case you should carefully check pros and cons of specific system to make decision, what is better for you.
IBM TOS, probably most reliable what I seen. For example my first leased line have TOS 99.9% (14 hours of downtime per month), and for most desktops and smartphones I don't seen any TOS at all (only guaranteed change if I found evidence of manufacturer defect within guarantee term, usually 1-3 years, depend on manufacturer).
But leased line and smartphones are not regulated in my country, and as I said before, controllers for smart buildings are regulated (sure, not all, but some functions are very strictly regulated, for example because of this exists huge proposal of second hand equipment, because near impossible to install it into other place after left spare because of upgrade).
But leased line and smartphones are not regulated in my country, and as I said before, controllers for smart buildings are regulated (sure, not all, but some functions are very strictly regulated, for example because of this exists huge proposal of second hand equipment, because near impossible to install it into other place after left spare because of upgrade).
You might also want to look at AvaloniaUI[0] for a cross platform .NET GUI library. It is similar to WPF but much nicer to work with.
[0] https://avaloniaui.net/
[0] https://avaloniaui.net/
That is also very interesting. Didn't know about it. Amazing how these things don't easily surface when you search. Thanks.
The GTK library might not be a terrible choice if you end up targeting Linux. It's fast to prototype with (in my experience) and very well-optimized for touch/tablet interfaces. Well worth checking out IMO: https://www.gtk.org/
Didn't know about this. Very interesting. Thanks.
You could consider Lazarus/Free Pascal for your project. I've run it on my Windows machines, and a Raspberry Pi Zero W. It does Linux, of course.
I've not yet tried to compile for Android or WASM, but in theory those are possible.
I've not yet tried to compile for Android or WASM, but in theory those are possible.
Bare metal or an RTOS.
Developing on Windows is easy for a range of reasons. Customers have people who can work with Windows, which means supporting them can be easier. My greatest concern with Windows are unwanted automatic updates. I think Windows IoT edition might bring this under control. Not sure. Also, I need to call a sales rep to understand their pricing/licensing model.
The fear isn't reboots. That's not a problem. It's the potential for an update causing our application to stop working correctly.
The alternatives are, of course, Linux and Android.
At that point we have to consider a multi-platform approach to development.
The one requirement is that it has to be a compiled language. The application-specific source cannot be open for a range of reasons, one of them being potential exposure to liability if source is modified and something goes horribly wrong. That leaves out frameworks that are web-centric JS/Python based.
The options I have considered include:
Qt: I am not comfortable with their licensing models and very slimy process. I watched a video presentation where the presenter broke down the license terms and highlighted deceitful language designed to make you believe you have to pay them money. Not for me.
Uno Platform: C# is fine. I's prefer C++, but that's just me. Being able to use .Net UI components sounds like a potential plus. Don't need much, buttons, sliders, menus, graphs, etc.
.Net MAUI does not support Linux. Other than that, possibly interesting. It does support Android.
Xamarin: No Linux but it does do Android. C# & .Net
Kotlin. Interesting. Java. No.
Wondering if anyone who may have walked this path might have something to share. Thanks.