Related
In Martin Fowler's book Patterns of Enterprise Application Architecture he writes on page 2: "In some ways enterprise applications are much easier than telecoms software -- we don't have very hard multithreading problems ...".
Is anybody aware of a summary of those "very hard multithreading problems" and solutions, in the form of design patterns, like the famous GoF Design Patterns book?
There is the POSA book. But those books might be too general and fundamental. More domain focused examples would be what this question is after.
Check out Joe Armstrong's thesis from 2003:
Making reliable distributed systems in the presence of software errors.
Armstrong designed the software for a high-speed network switching device during his time at Ericsson. It was implemented in Erlang, which was specifically designed to provide highly reliable and highly concurrent applications.
In his thesis, he presents the underlying design decisions for the Erlang language itself and the OTP (Open Telecom Platform) library. He also makes some suggestions about how to design application modules for such applications -- this part comes closest to your 'design pattern', although not in the detail you're accustomed to after reading GoF's Design Patterns.
It's not a recipe book, but he nevertheless draws a few interesting conclusions about how applications should be designed.
Actors
The actor model an architectural pattern where a system is made up of a set of loosely-coupled actors that interact through message passing.
An actor is a computational entity that, in response to a message it receives, can concurrently:
send a finite number of messages to other actors;
create a finite number of new actors;
designate the behavior to be used for the next message it receives.
One of the properties of such a system is that failure propagation is reduced, and as a consequence individual actors become more robust.
The programming language Erlang was specifically designed for telephony switches and supports the actor model.
State Machines
A pattern that is common in real-time & embedded software engineering are state machines. State machines can be implemented on top of actors, but also provide a mechanism to represent complex states and associated behavior.
Finite state machines (FSM) are a possibility, but they quickly start to get large and difficult to maintain because of State Explosion. A more expressive formalism that solves this problem are Hierarchical State Machines (HSM) as originally developed by David Harel.
A more recent implementation of the same semantics that fits object-oriented design is the UML State Machine, see Section 15 of the UML specification. This defines a model for state machines complete with their execution semantics.
How can we analyze the software reliability? How to check the reliabilty of any application or product?
First try to define "software reliability" and the way to quantify it.
If you accomplish this task, you will probably be able to "check" this characteristic.
The most effective way to check reliability is going to be to run your software and gather statistics on its actual reliability. There are too many variables in play, both at the hardware and software levels, to realistically analyze reliability prior to execution, with the possible exception of groups with massive resources like NASA.
There are various methods for determining whether a piece of software meets a specification, but most of the really productive ones do this by construction, i.e., by constraining the way in which the software is written so that it can be easily shown to be correct. Check out VDM, Z and the B toolkit for schemes for doing this sort of thing. Note that these tend to be expensive ways to program if you're not in a safety-critical systems environment.
Proving the correctness of the specification itself is really non-trivial!
Reliability is about continuity of correct service.
The best approach to assess reliability of a software is by dynamic analysis, in other words: testing.
In order to reduce your testing time you may want to apply input profiles different from operational one.
Apply various input distributions, measure how much time your software runs without failure. Then find out how far your input distributions are from operational profile and draw your conclusion about how much time the software would have run with operational profile.
This involves modeling techniques such as Markov chains or stochastic Petri nets.
For further digging, useful keywords are: fault forecasting and statistical testing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I didn't find any useful information about programming languages for real time systems. All I found was Real Time Systems and Programming Languages: Ada 95, Real-Time Java and Real-Time C/POSIX (some pdf here), which seems to talk about extensions of Java and C for real times systems (I don't have the book to read). Also, the book was published in 2001, and the information may be obsolete now.
So, I'm dubious whether these languages are used in real world applications, or if real time systems in the real world are made in other languages, like DSLs.
If the second option is true for you, what are the outstanding characteristics of the language you use?
I am an avionics software engineer.
I was able to participate in several development projects.
The languages I used in those projects are: C, C++, and Real-time Java.
C is great.
C++ is not so bad but C/C++ require strict coding standards for the safety considerations such as DO-178B.
I think Real-time Java is the way to go but I don't see many avionics applications, yet.
Korean jet trainer T-50 will have a mission computer running RT Java application serving HUD and MFD displays, and all of the mission critical functions.
The Real-Time Specification for Java now has several commercial-grade implementations:
Sun's JavaRTS
IBM's WebSphere Real-Time
Aonix PERC
aicas JamaicaVM
Apogee Aphelion
These products span the continuum from compilation to native code (Aonix) to J2ME (aicas, apogee), to full J2SE (Sun, IBM). Most, if not all, have seen deployments in small numbers of safety- or mission-critical systems, but momentum is building. Examples include Eglin AFB's space surveillance radar modernization and the US Navy's use of RTSJ in the DDG-1000/Zumwalt destroyer. Sun also claims deployment in the financial transaction processing domain.
If you are interested in RTSJ, I suggest Peter Dibble's Real-Time Platform Programming, or Professor Wellings' Concurrent and Real-Time Programming in Java.
On a related note, there is also work underway to provide a Safety-Critical profile for the Java programming language, built as a subset of RTSJ. Also, an expert group has formed to explore a Distributed RTSJ DRTSJ, but the work is stalled.
The book covers use of Ada 95, the Java Real-Time System and realtime POSIX extensions (programmed in C). None of these is directly a domain specific language.
Ada 95 is a programming language commonly used in the late 90s and (AFAIK) still widely used for realtime programming in defence and aerospace industries. There is at least one DSL built on top of Ada - SparkAda - which is a system of annotations which describe system characteristics to a program verification tool.
This interview of April 6, 2006 indicates some of the classes and virtual machine changes which make up the Java Real-Time System. It doesn't mention any domain specific language extensions. I haven't come across use of Java in real-time systems, but I haven't been looking at the sorts of systems where I'd expect to find it (I work in aerospace simulation, where it's C++, Fortran and occasionally Ada for real-time in-the-loop systems).
Realtime POSIX is a set of extensions to the POSIX operating system facilities. As OS extensions, they don't require anything specific in the language. That said, I can think of one C based DSL for describing embedded systems - SystemC - but I've no idea if it's also used to generate the embedded systems.
Not mentioned in the book is Matlab, which in the last few years has gone from a simulation tool to a model driven development system for realtime systems.
Matlab/Simulink is, in effect, a DSL for linear programming, state machines and algorithms. Matlab can generate C or HDL for realtime and embedded systems. It's very rare to see an avionics, EW or other defence industry real-time job advertised which doesn't require some Matlab experience. (I don't work for Matlab, but it's hard to over emphasis how ubiquitous it really is in the industry)
Real time applications can be made in almost any language. The environment (operating system, runtime and runtime libraries) must however be compliant to real time constraints. In most cases real-time means that there's always a deterministic time in which something happens. Deterministic time being ussually a very low time value in the microseconds/milliseconds range.
Real time systems depend solely on this criteria, as the specificiations usually say something like 'Every x (period of time) (do something | check something)'. Usually this happens if the system interfaces with external sensors and controls life-saving or life-threatening systems.
I was working on an in-car navigation and infotainment system developed mostly in C/C++ with an operating system configured specifically to meet the real-time constraints to provide real-time navigation and media playback.
But this is not all to real-time systems: Usually the selection of algorithms in the entire system is made to have deterministic runtimes according to the Big-O notation, mostly using linear or constant time. Everything else is considered non-deterministic and thus not useable for real-time systems.
All of the real-time systems I have worked with were predominantly written in C with some bits of assembler, or written mostly in assembler with little bits of C. (Depending on whether we're talking the 90s and beyond, or the 80s, respectively.) However, some of the real-time systems I've worked with have used -- not exactly DSLs -- special homegrown code generators.
Real-time oriented language?
What is real-time
First we have to define what real-time mean.
Of course depending on how your tool will work against the physical environment pure real-time couldn't be effectively done, mostly because there will be a lot of third party dependencies.
If you are building embed stuff by using microcontrollers like arduino, the language to use will be limited by the hardware, but with more complex stuff like Raspberry Pi, the language choice is very wide.
Granularity
This is depending on what you are measuring, if you're working with:
weather temperatures, one read each 10 minute could be enough
people height or weight, one or maybe four read by day
server status, between 1 second for fine debugging to approx 1 hour for quiet unimportant secondary server.
atomic collision count: something finer...
Event based reading
The right (better) way for collecting data is based on value change event... whenever the device do permit it.
Your tool have to not poll values from device, but the device have to send values to your tool, when they change.
This could be done by using an hardware interrupt trigger or by using port protocole like RS-232 staying listening on some serial port, for sample.
Monitoring environment
The last thing to be warned is how legitimate user will interact with.
If you're building embed standalone device, like robot, you may use graphic libraries to interact with touch screen.
If you're building web based monitor, you may have to keep in mind that the client could be an old 800x600 monochrome screen, using poor internet connection and small processor... But depending on final goal if you may interact with clients, you could ensure strong hardware and strong internet connections. Anyway you have to watch for connexion loosing and event for communication delay between server and client. There is mostly third party dependencies.
Which programming language?
From there, the language choice is wide and clearly depend on
your knowledge.
granularity requested (by using event-based too, of course)
the amount of time you have to build the tool (money;)
delay, co-workers...
kind of device
kind of monitoring
some other political reasons
You could build real-time monitoring engine by using bash and sql only, I've seen sophisticated engines that was built under postgresql only... I've personally built a web based, solar energy monitor by using perl, mysql and javascript.
I cannot believe no one has mentioned LabVIEW programming language which is widely used for Real-time safety-critical systems. It has extensive libraries and well-known design patterns for architecturing and implementing for RT systems.
Also National Instruments makes various hardware (cRIO, PXI and etc) which are designed for real-time applications.
We use LabVIEW for Fracking (Hydraulic Fracturing) which is used in safety-critical environments.
PLCs run ladder and fbd code which is really a real-time dsl in the sense that your options are so limited that it is difficult to program in a way that would result in unpredictable runtime performance
A really purposeful application of the C language to real-time programming - and all related issues (such as parallel programming) - is offered by my Kickstarter
http://www.kickstarter.com/projects/767046121/crawl-space-computing-with-connel
It is called "Wide Programming" and I've been doing it most of my life. The rewards include a software library and a book - designed to be useful.
the company I've been working for since 2003 has been developing and deploying a Scada/Mes platform. Original implementation started in 1993, used Modula2 on OS/2. Later (1998) it was ported to Ada95 and Windows. Currently (2019) we use Ada compiler by AdaCore. Our system was ported and has been deployed to 32/64 Windows, HPUX, OpenVMS (and lately even to Raspberry). We have multiple installation in central Europe (gas industry, refineries, factories, power plants).
We feel Ada's features give our system a high degree of reliability and prevents a lot of errors that would easily occour if we used languages like C.
See also my blog
https://www.ipesoft.com/en/blog/what-language-is-the-d2000-written
We are currently setting up the evaluation criteria for a trade study we will be conducting.
One of the criterion we selected is reliability (and/or robustness - are these the same?).
How do you assess that software is reliable without being able to afford much time evaluating it?
Edit: Along the lines of the response given by KenG, to narrow the focus of the question:
You can choose among 50 existing software solutions. You need to assess how reliable they are, without being able to test them (at least initially). What tangible metrics or other can you use to evaluate said reliability?
Reliability and robustness are two different attributes of a sytem:
Reliability
The IEEE defines it as ". . . the
ability of a system or component to
perform its required functions under
stated conditions for a specified
period of time."
Robustness
is robust if it continues to operate despite abnormalities in input, calculations, etc.
So a reliable system performs its functions as it was designed to within constraints; A robust system continues to operate if the unexpected/unanticipated occurs.
If you have access to any history of the software you're evaluating, some idea of reliability can be inferred from reported defects, number of 'patch' releases over time, even churn in the code base.
Does the product have automated test processes? Test coverage can be another indication of confidence.
Some projects using agile methods may not fit these criteria well - frequent releases and a lot of refactoring are expected
Check with current users of the software/product for real world information.
It depends on what type of software you're evaluating. A website's main (and maybe only) criteria for reliability might be its uptime. NASA will have a whole different definition for reliability of its software. Your definition will probably be somewhere in between.
If you don't have a lot of time to evaluate reliability, it is absolutely critical that you automate your measurement process. You can use continuous integration tools to make sure that you only ever have to manually find a bug once.
I recommend that you or someone in your company read Continuous Integration: Improving Software Quality and Reducing Risk. I think it will help lead you to your own definition of software reliability.
Talk to people already using it. You can test yourself for reliability, but it's difficult, expensive, and can be very unreliable depending on what you're testing, especially if you're short on time. Most companies will be willing to put you in contact with current clients if it will help sell you their software and they will be able to give you a real-world idea of how the software handles.
As with anything, if you don't have the time to assess something yourself, then you have to rely on the judgement of others.
Reliability is one of three aspects of somethings' effectiveness.. The other two are Maintainability and Availability...
An interesting paper... http://www.barringer1.com/pdf/ARMandC.pdf discusses this in more detail, but generally,
Reliability is based on the probability that a system will break.. i.e., the more likely it is to break, the less reliable it is... In other systems (other than software) it is often measured in Mean Time Between Failure (MTBF) This is a common metric for things like a hard disk... (10000 hrs MTBF) In software, I guess you could measure it in Mean Time between critical system failures, or between application crashes, or between unrecoverable errors, or between errors of any kind that impede or adversely affect normal system productivity...
Maintainability is a measure of how long/how expensive (how many man-hours and/or other resources) it takes to fix it when it does break. In software, you could add to this concept how long/how expensive it is to enhance or extend the software (if that is an ongoing requirement)
Availability is a combination of the first two, and indicates to a planner, if I had a 100 of these things running for ten years, after figuring the failures and how long each failed unit was unavailable while it was being fixed, repaired, whatever, How many of the 100, on average, would be up and running at any one time? 20% , or 98% ?
Well, the keyword 'reliable' can lead to different answers... When thinking of reliability, I think of two aspects:
always giving the right answer (or the best answer)
always giving the same answer
Either way, I think it boils down to some repeatable tests. If the application in question is not built with a strong suite of unit and acceptance tests, you can still come up with a set of manual or automated tests to perform repeatedly.
The fact that the tests always return the same results will show that aspect #2 is taken care of. For aspect #1 it really is up to the test writers: come up with good tests that would expose bugs or imperfections.
I can't be more specific without knowing what the application is about, sorry. For instance, a messaging system would be reliable if messages were always delivered, never lost, never contain errors, etc etc... a calculator's definition of reliability would be much different.
My advice is to follow SRE methodology around SLI, SLO and SLA, best summarized in free ebooks:
Site Reliability Engineering which provides principal introduction
The Site Reliability Workbook which comes with concrete examples
Looking at the reliability more from tool perspective you need:
monitoring infrastructure (I recommend Prometheus)
alerting (I recommend Prometheus AlertManager, OpsGenie or PagerDuty)
SLO computation tooling for instance slo-exporter
You will have to go into the process by understanding and fully accepting that you will be making a compromise, which could have negative effects if reliability is a key criterion and you don't have (or are unwilling to commit) the resources to appropriately evaluate based on that.
Having said that - determine what the key requirements are that make software reliability critical, then devise tests to evaluate based on those requirements.
Robustness and reliability cross in their relationship to each other, but are not necessarily the same.
If you have a data server that cannot handle more than 10 connections and you expect 100000 connections - it is not robust. It will be unreliable if it dies at > 10 connections. If that same server can handle the number of required connections but intermittently dies, you could say that it is still not robust and not reliable.
My suggestion is that you consult with an experienced QA person who is knowledgeable in the field for the study you will conduct. That person will be able to help you devise tests for key areas -hopefully within your resource constraints. I'd recommend a neutral 3rd party (rather than the software writer or vendor) to help you decide on the key features you'll need to test to make your determination.
If you can't test it, you'll have to rely on the reputation of the developer(s) along with how well they followed the same practices on this application as their other tested apps. Example: Microsoft does not do a very good job with the version 1 of their applications, but 3 & 4 are usually pretty good (Windows ME was version 0.0001).
Depending on the type of service you are evaluating, you might get reliability metrics or SLI - service level indicators - metrics capturing how well the service/product is doing. For example - process 99% of requests under 1sec.
Based on the SLI you might setup service level agreements - a contract between you and the software provider on what SLO (service level objectives) you would like with the consequences of not them not delivering those.
I've heard that the automotive industry has something called MISRA C.
What are the relevant standards for other high reliability/availability/security industries, such as
Space
Aircraft
Banking/financial
Automotive
Medical
Defense/Military
???
-Adam
Check out the Goddard Space Flight Center and its coding standards. One of the C standards, which I've adopted in my own code, is that headers must be self-contained, and they provide a simple way to enforce that -- a module's header must be the first file included in the module, so if the file is not self-contained, it won't compile.
if you're asking specifically about coding, the MISRA presents some guidelines for avoiding common mistakes in C.
however, there's a lot more to good software than coding. The "bible" of the aviation industry for sw development is DO-178B. It tells you what questions need to be addressed in the various design phases and how the answers should be documented. It's an ENORMOUS amount of paperwork, but if you're trying to keep planes in the air, you want the weakest point to be the human (pilot), not the software.
For programming high reliability systems in Ada, there is: ISO/IEC TR 15942:"Information technology — Programming languages — Guide for the use of the Ada programming language in high integrity systems":
Introduction
As a society, we are increasingly
reliant upon high integrity systems:
for safety systems (such as
fly-by-wire aircraft), for security
systems (to protect digital
information) or for financial systems
(e.g., cash dispensers). As the
complexity of these systems grows, so
do the demands for improved techniques
for the production of the software
components of the system. These high
integrity systems must be shown to be
fully predictable in operation and
have all the properties required of
them. This can only be achieved by
analysing the software, in addition to
the use of conventional dynamic
testing. There is, currently, no
mainstream high level language where
all programs in that language are
guaranteed to be predictable and
analysable. Therefore for any choice
of implementation language it is
essential to control the ways that the
language is used by the application.
The Ada language [ARM] is designed
with specific mechanisms for
controlling the use of certain aspects
of the language. Furthermore,
The semantics of Ada programs are well-defined, even in error
situations. Specifically, the effect
of a program can be predicted from the
language definition with few
implementation dependencies or
interactions between language
features.
The strong typing within the language can be used to reduce the
scope (and cost) of analysis to verify
key properties.
The Ada language has been successfully used on many high
integrity applications. This
demonstrates that validated Ada
compilers have the quality required
for such applications.
Guidance can be provided to facilitate the use of the language and
to encourage the development of tools
for further verification.
Ada is therefore ideally suited for
implementing high integrity software
and this document provides guidance in
the controls that are required on the
use of Ada to ensure that programs are
predictable and analysable.
You may find it instructive to look at some of the requirements of Carrier Grade Linux. While they (as the name suggests!) are specifying linux requirements, they are doing so for use in the high availability segment of telecommunications equipment.
FDA has General Principles of Software Validation, Design Control Guidance For Medical Device Manufacturers, Guidance for Industry, FDA Reviewers and Compliance on
Off-The-Shelf Software Use in Medical Devices, etc.
NIST provides a whole slew of related documents, you can dive in and peruse their work - but there is a lot of it, and it's all quite verbose, so I dont have a specific one to point you at.
If you want to be more specific with your needs, I might be able to narrow it down a bit...
In addition, Carnegie Mellon is pretty much the definitive when it comes to development processes for reliability, easy enough to find their standards but also quite verbose.
Also, specific industries often have their own standards, depending also on the country. For instance, credit card industry - PCI-DSS; Banking industry in EU - Basel II; Medical - HIPAA (though thats pretty high-level); anything US government related, various NIST docs; etc.