A little of topic, but I'm confused about something.
These certs open the door for medical devices, which is great.
I work on Class 1 medcial device. We have customers and regulatory people saying I can't even use Qt because we compile it ourselves. Apparently, once we have access to the source code, we must bring the software up to our target safety class.
This of course isn't feasible. Apparently, this even applies to the kernel.
My regulatory people are demanding that we hire someone like WindRiver to deliver use pre-compiled images and tool chains, removing the source from our hands.
I don't follow regulatory closely, but this has got to be wrong. Are you saying that I can never use open source software? Even if the software has these certs like this (Safe Render)? Surely we can still treat 3rd party libs as SOUP, even if we have the source, yeah?
You can use any SOUP you want, the rule is that it is up to you, medical device seller, to write the requirements (performance or other) you want from it, and verify them. Additionally, you need to assess any risk added by the inclusion of the SOUP and mitigate them. (The effort depends on whether you include it into a Class A/B/C sw unit). You are ultimately responsible for any bug in the SOUP. And this is rather orthogonal to license of the sw.
Since this is a daunting task to verify something like QT, now you can at least pay for the certified version, and point some of your risk mitigations directly to the QT specifications/FMEA/Test results.
The usual strategies to avoid having to validate a huge external SW is to either have HW redundancies, or to segregate it completely from your main SW so that any failure of your SOUP is harmless.
We use Yocto. By default, the distribution is super minimal.
As I enable features in the Kernel, or add dependencies, they are driven based off of some functionality of our GUI/device which is tested/validated before each release.
So, if I enable squashfs in the kernel, and I can boot my box (which uses it), I can say that I have tested the requirements needed from the Kernel.
If I add in openssl for TLS connection to mobile devices and have validation in place to ensure connectivity, I can say that I have tested the required functionality of openssl.
I'd think this would be enough, but I never can seem to satisfy regulatory people. They are (in general) not very technical.
I would say it depends a bit of the usage of the system, and what is the worse case scenario of a failure (patient data corrupted, life sustaining devices switched off), in which case you might need to add another mitigation (CRC check, manual procedure) independent of your Yocto box.
I would understood under those circumstances where patients are at risk.
I'm not trying to get consultation services from HN, but for the sake of discussion, these devices are recorders used for post-op educational purposes. External/separate monitors are used for the actual operation.
I bring this up because the risk is very low, yet I have had multiple customers who wish to distribute our product ask about this.
This is turning into more of a rant than anything. I'll end with this comment.
You aren’t expected to do anything in analysis and mitigation for SOUP that you shouldn’t already be doing for all of your own software. The point is you can’t just punt on that stuff when you use others software. It doesnt have to be that onerous, but you do need to put some thought into it.
I know nothing about this... However, I can see a little bit of sense to this (not much - and nothing that couldn't be solved a lot better). If you have access to the source code it is very easy to start adding patches. On the other hand if you have access to binaries it is also very easy to start modifying them...
That’s not a very accurate analogy. The situation would be more like “you can only use a pre-compiled, audited version of OpenSSL”, which makes much more sense. Of course you could audit source code as well, but it’s much harder to verify than a binary.
I should probably clarify: it’s easier to make sure that a binary is the same as a version that has been audited, whereas with source code, there’s much more uncertainty in the build process.
With Yocto, you can audit the recipes (example [0]) being used to build the library.
Yocto all generates checksums for all inputs and outputs, caching intermediate build steps, ensuring consistency in the build process.
Also, Yocto will not compile anything with your local/native gcc toolchain. It will however use your local gcc toolchain to build it's own gcc toolchain, which it will then use to build all the relative recipes. This again ensures build consistency across platforms/machines.
If the argument is purely a "well, I can't audit the produced binaries", I'd argue that you can audit the build system in great detail.
I don't work in the field, but just because you're using a certified binary doesn't mean no source can ever be associated with it for debugging.
Continuing the example of a certified binary of openssl from a third party (say version 1.1.0h), I'd expect you to be able to debug the certified binary using a version-matched source tarball from the openssl website [1].
ASIL-D, SIL 3, SIL 4 und IEC 62304:2015(2006+A1) certifications mean that Qt can now officially be used for displays in automotive, medical devices, trains etc.
For safety critical displays, that is. A big share of IVI systems used Qt and QML for years; with this component, the same stack (Qt+QML) can be used for the primary driver displays, including warning and damage lamps.
Until now these indicators were almost always actual physical lamps; the information displays often found in the center between tacho- and speedometer don't use any kind of fancy graphics at all; they're mostly just black and white LCDs driven by the ECU over the CAN bus.
I've always been very impressed by the work of the Qt teams. I don't do much coding in C++ but when I have dabbled in it using Qt feels like a breath of fresh air.
yeah, after working in the web world and being depressed by javascript apps that consume 100% CPU doing nothing to render a page of ads, I love to go back to Qt and spend 5 minutes writing a high performance app that does amazing things.
It's really incredible how the world of software developed by adults differs from the software developed by kids.
That's just so out of touch with reality. People with that attitude scare me because they lock us into the "one true solution" rather than the one that actually makes the company successful. Nobody pretends that JS/electron apps are supafast, but don't pretend like they don't have tremendous benefits too.
there are many true solutions, electron is not one of them though.
>but don't pretend like they don't have tremendous benefits too.
Javascript+html+css is not a global optimum in the solution space of "making cross platform GUI apps", its just the best solution that exists right now (if you are afraid of C++), and that is too bad.
We could have simpler, better performing ways if we bothered to do things that aren't web related more often.
Iterating front-end development with Javascript+html+css is simpler and quicker than doing the same with C++ because you don't have to recompile for each iteration. In some cases I don't even need to restart the app.
Also, I have been able to debug in a few nasty cases by getting users to switch out a js/html file and restart the app. That's impossible to do with C++ given the same time/effort constraints.
Those are just two fairly small but measurable examples. There are also drawbacks to having not chosen Qt for the front-end. But those data points and more were part of a rather complicated cost-benefit analysis of what was available to make a cross platform GUI app in a reasonable amount of time.
I don't see what a search for a "true" toolkit has to do with such an analysis. I don't see what caricatures of one camp or another as unduly emotional has to do with such an analysis. What am I missing?
You should do some Qt frontend development some time. A lot of is done in QML and doesn't need recompilation, and can be hot-reloaded at runtime. It's a false dichotomy, Qt offers these benefits to a great extend when used well.
But time and money is a real constraint for projects. It's hard enough writing native Android, native iOS, and a web app to boot without also having to write native Mac, Linux, and Windows and dealing with all the cross platform UI quirks on Qt.
This is in reference to using Electron so you don't have to both write a web app and a native desktop app using Qt (in addition to native mobile, where performance issues are much more noticeable).
Any OS-quirks you experience with Qt are likely the nature of cross-development (path separators, toolbars, sys-trays), stuff that you'd likely experience with any framework.
what, exactly does electron get us over native apps? Be specific. I've used them, they look and feel like most other apps, but tend to be slower and more buggy.
A faster turnaround time for updates and bug fixes, enabled by removing the minutiae of developing cross-platform apps.
Now tell me, what do native apps get you over Electron apps? Demonstrably happier customers? Or just the personal satisfaction of knowing your app is a "global optimum" or whatever?
> A faster turnaround time for updates and bug fixes, enabled by removing the minutiae of developing cross-platform apps.
I'd say what you are arguing is "my team is better at JavaScript than Qml/JavaScript/C++", which is fine. It really boils down to what the team is most comfortable writing in.
That aside, Qt definitely wins when compared to Electron.
Less memory. Less disk space. When a critical bug is found in the electron runtime, you'll have to trust all those packaged electron versions get updated in time.
Let's be fair here, if you're running on anything but Linux you're hoping every application updates their bundled Qt frameworks when there's a bug found in it too.
> A faster turnaround time for updates and bug fixes, enabled by removing the minutiae of developing cross-platform apps.
what makes you say that ? I develop a C++/Qt app and fix bugs and add new features without any problems and without having to care to mac / windows / linux specific stuff.
No, it's not. It's an accurate assessment of the current state of the web world: web frameworks that last a year before they get abandoned by their creators. jwz wrote a nice blog post about it: https://www.jwz.org/doc/cadt.html
A guy who has maintained a secure screensaver for 20+ years. Who aptly describes how fucked up our system is.
Who built the technology your browser apps are based on.
Not that he's wrong about open-source abandonware, but that's rather an overstatement. No significant amount of his code remains in any modern browser, and when the engine that eventually became WebKit and later Blink (and which now powers the majority of end-user web client browsing today) was first announced as based off KHTML and not Mozilla tech, he wrote a self-congratulatory blog post[0] that started off with "Summary: I was right", even though it had nothing to do with him or his work. Not to mention KHTML was done using C++, something he was always against (no mention of "I was right" on that part, I see). He's done some good work here and there but he really gets carried away with his blowhard opinionating at times, and I think people should turn a more critical eye towards that sort of thing.
shrug Nothing wrong with native code, and sometimes nothing else will get the job done. Besides, my retirement plan is to be the dinosaur brought out to fix all those 32-bit-time bugs in 2038.
Low level knowledge is useful at times. I rewrote a small amount of code on a project at work using SIMD instruction to reduce execution time by 60%. This is on something executes in tens of minutes so the time savings are quite noticeable.
most of my code is in Python (there are Qt bindings). That said, I'm interested in webassembly, and can also write javascript. I just don't think that browsers or javascript-based apps present a preferred alternative to native apps developed by teams who consider long-term API stability and getting the right regulatory boxes checked.
The free performance lunch from ever faster hardware is over and that is saving native code for applications. The few percent hardware improvement each year is easily eaten by growing requirements.
I've been using this for a few internal "worklists" for customer service. It works great and I didn't have to learn JS.
It's not quite like Qt but it tries to follow the same style.
The quality is not quite up to par with Qt either but it was definitively good enough for the internal projects.
'It's really incredible how the world of software developed by adults differs from the software developed by kids.'
Well, if I may... What actually tells adults and children developers apart is their swift ability to bring nuances (like in 'pros n cons') on the table when choosing the more efficient techno for a given problem. Yes, Qt has great pros. No, Qt is obviously not The Silver Bullet.
> It's really incredible how the world of software developed by adults differs from the software developed by kids.
I don't really agree with this sentiment. JavaScript has become one of the better languages to work in these days. I'd much rather work in JavaScript than C++ any day.
Are the 'safety critical' UI components rendered any differently to the non-critical ones? From reading the related blog posts, I understand that they are generated in a separate process, but asides from that detail, are they any more reliable?
Or to put it another way, if we an pick some UI components and marking them as safety critical' somehow improves their reliability, why would you not mark everything as safety critical?
Does the safety factor decrease as more and more components enter the safety critical section? Why not subdivide the UI into more than just one 'critical' process and one 'non-critical' process, e.g. perhaps a light-weight process per component?
I talked to one of the devs a whule ago: the safety critical part of the display is rendered by a completely separate renderer which is kept as simple as possible. Most of the application specific code for it is generated automatically and a lot of the typical dynamic behaviour (dynamic memory allocation etc.) is strictly forbidden so that the result follows the requirements of safety standards.
Aviation has their own standards. But all of these standards are quite similar in their requirements. So reaching the first certification is the hardest part.
Friendly neighbourhood aerospace systems engineer here.
Yes, the certifications on the aviation side are DO-178C for Software and DO-254 for Airborne Electronic Hardware. Rather than SIL or ASIL (Automotive Safety Integrity Level), the aviation equivalent is DAL (Development Assurance Level). Of course, while they each use letters for levels of Integrity / Assurance, in aviation DAL A is the most stringent and in automotive ASIL-D is the most stringent.
Ah yes I took the 5 day greenhills training for a project that got put on hold. Was wondering if anything opensource exist for do187b usage. For example a GCC toolchain and a standard set of libraries (apart from the OS)
When I'm seeing TÜV seals for highly-complex IT-related topics, I'm always asking myself if the people working for TÜV are really qualified for doing such certifications. The TÜV historically inspected steam engines and is mostly known today for doing driving tests.
Here in Germany, the TUEV not only certifies nuclear power plants, but will be involved in most of the precursory steps (the politics of a general 'Atomausstieg / nuclear power phase-out' aside for the moment)
This does not really mean Qt (and/or QML) is certified. It means there is support in QtCreator for exporting certain graphics (tell tales) so that they can be rendered by Qt Safe Renderer and if that happens on a certified RTOS the system could be certified.
So the Qt libraries or QML renderer are still not certifiable.
Nor will they ever be, at least at that high level. The standards are very strict about what is allowed in the code and Qt is coded in a way that is fundamentally incompatible with that.
But that is okay. Isolating the core components that have the highest safety requirement and developing the rest to a lower standard is accepted and good practice. You also need to have an operating system that enforces the separation and a design that guarantees that the safety critical part cannot be disrupted by failures in the rest of the system.
For example, a fancy navigation map display is not safety critical at all and developing that to ASIL standards would be madness. Icon ovelays for engine or braking system failures are quite important, on the other hand. Separating then out into a different process and making sure that it cannot be affected by a misbehaving navigation system is just common sense. So even with the current limits, this is very useful.
Sure, I agree that you should limit ASIL certified software as much as possible. Nothing running on Linux will be certified ever.
That also limits the benefits of Qt Safe Renderer. I think it is mostly a marketing thing within the automotive sector. The competitors there (Disti, Kanzi, etc) have their "solutions" for safety critical and say Qt can't handle it. So Qt needs to check the box of "safety critical" to fend for themselves.
Tell tales can quite simply be implemented by hand coding.
But there is OpenGL SC which possibly could support more fancy and certified graphics. It could be nice if Qt/QtCreator/Qt3dStudio supported that in some manner. Having a layer that is safety critical and separated out to it's own OpenGL SC code. The usual argument for this kind of stuff is that nice graphical ADAS features (think advances HUDs) will need this (although I think it is still reasonable to hand code it in OpenGL SC).
Just to be clear, QT still has the same licensing, correct?
dual:LGPL or commercial
commercial license costs + not redistributable (example, if included in a BSD or MIT library/framework/tool...)
or LGPL (also requires project to be LGPL)
just checking, as it's a factor in why Qt is not universal, but only ubiquitous, which is still a good thing, because "diversity" and not wanting to put the fate of all gui forever into the hands of one entity etc..
but: any other declarative (like qml) gui frameworks out there in Linux land?
Note that some modules are not available under the LGPL. You don't get charts, data visualisation or any of the embedded tooling.
LGPL does not require the project to be LGPL. It simply means that you must provide users means to link your program to a version of Qt that they've compiled, or you provide the source of the Qt distribution that you compiled to build your application. You can have a commercial, closed-source, application using LGPL Qt.
"A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License."
Contrary to popular belief you can even statically link an LGPL library and remain closed source, but you may need to distribute your object files so that someone can statically link a different library version with your code.
I'm not sure what happens if you modify Qt in some way though, presumably you're still covered if you release the modifications you made.
If you provide a version that can be dynamically linked against a users' self-compiled QT version, can you release a statically compiled version alongside it and still be compatible with the license?
> If you provide a version that can be dynamically linked against a users' self-compiled QT version, can you release a statically compiled version alongside it and still be compatible with the license?
you can release a statically linked version and share your compiled proprietary object files (+ build instructions) ; that's enough to comply with LGPLv3
For charting, Qwt is a pretty mature library now. The documentation is somewhat sparse, but complete if you look at the Doxygen + examples as well. The author is active on the Qt forums too.
> but: any other declarative (like qml) gui frameworks out there in Linux land?
I don't see how the license is a problem. It used to be not 100% open source but it is now, and it has a commercial license if you don't want to open source your program. You can also dynamically link to LGPL versions of the library from your program. [1]
In any case, to answer the question, you have guile gnome [2] which sort of does the same thing but in a scheme language.
These certs open the door for medical devices, which is great.
I work on Class 1 medcial device. We have customers and regulatory people saying I can't even use Qt because we compile it ourselves. Apparently, once we have access to the source code, we must bring the software up to our target safety class.
This of course isn't feasible. Apparently, this even applies to the kernel.
My regulatory people are demanding that we hire someone like WindRiver to deliver use pre-compiled images and tool chains, removing the source from our hands.
I don't follow regulatory closely, but this has got to be wrong. Are you saying that I can never use open source software? Even if the software has these certs like this (Safe Render)? Surely we can still treat 3rd party libs as SOUP, even if we have the source, yeah?