I'm new to Autosar and trying to understand the concept theoretically.
I understand the philosophy, the goal, and the uses, but one thing that I don't completely understand is whether Autosar contains some out-of-the-box software components for developers? And if yes how can I recognize them in a binary file?
Assuming that the question uses the term “software-component” according to the meaning in AUTOSAR as some piece of application-level software:
no, there are no software-components standardized by AUTOSAR. There are PortInterfaces that are standardized and out of those PortInterfaces software-components could be created.
And also, some specifications postulate the existence of specific software-components, but this represents actually the opposite of a standardization. Those software-components are mostly postulated because it is not possible to standardize the respective functionality within the respective basic-software module (OEM/suppliers have proprietary approaches that they want to keep).
AUTOSAR defines an architecture with certain methodology and exchange formats. The BSW below and including the RTE is also specified. The BSW modules/components and their interfaces are standardized and include the MCAL, HW Abstraction and Service Layer components.
From your question it's a bit unclear what you mean with
some out-of-the-box software components for developers
I am looking for a primitive system like Z-scale or Cortex-M0 to start a research project. It looks like Z-scale is deprecated and does not comply with the latest RISC-V specifications. Is it possible to design a system like Cortex-M0 in Rocket Chip that has very primitive components and small footprint (e.g. gate count)?
I have tried Rocket Chip's DefaultSmallConfig, but it looks like this config supports relatively complicated subsystems such as division operation. What are the parameters I should consider in order to design a Z-scale-like or Cortex-M0-like core/system (e.g. no division, floating-point operations, etc.)?
Rocket chip can't generate the simplest RISC-V variants.
You may find one of these alternative RISC-V implementations more suitable.
PicoRV32 is area optimized, but takes 4 cycles per instruction:
https://github.com/cliffordwolf/picorv32
ORCA is written in VHDL:
https://github.com/VectorBlox/orca
The uRV is good enough for CERNs LHC:
https://www.ohwr.org/projects/urv-core
SCR1 has JTAG debug:
https://github.com/syntacore/scr1
There are many more implementations out there.
Look at VexRiscv (https://github.com/SpinalHDL/VexRiscv), there is two small SoC demo (Briey/Murax) and this CPU is highly customisable via an plugin system.
The motivation for this question is a far-fetched dream I have where a lot of the excellent software available on *nix platforms could be trivially ported to Windows. Microsoft has taken a different approach to open source and openness in general recently, so I'd really like to know how viable such a thing would be if Microsoft were so inclined. Some of the more specific things I'm curious about is if it could be done without breaking backwards compatibility, and perhaps some sort of gauge on the amount of effort that would be involved. If there were any specific technical examples that would highlight particular difficulties in doing such a thing, that would also be greatly appreciated.
Windows has already been such. The NT kernel itself has supported the concept of "personalities" (API layers over the NT layer) since the beginning, to support by design at the very least the Win32 API, the POSIX API and the OS/2 API.
The POSIX layer circulated for a long time in higher end SKUs (typically server-related) with different names (Microsoft POSIX subsystem/SFU/SUA), but it never really caught on for non-specialized use, both because it was not universally available (Microsoft never really pushed it, probably for commercial reasons) and because other solutions became widespread (think Cygwin/MSYS/MinGW).
Notice that, although the "personality API" is an interesting concept (and probably one of the cleanest way to implement a multi-API OS) it suffers a bit from a "deep segregation" problem - i.e., it's true that you can access kernel objects through a POSIX interface, but all services that have been built over the Win32 interface (like Windows, GDI & co.) aren't easily available; besides, however good the interface may be, there are some details (like the format of paths) that cannot be ironed over, so a POSIX application will always look a bit out of place.
I'm doing a trade study for Ada development on Linux. Do you have any good compiler/OS recommendations?
So far, I've got GNAT from AdaCore running on CentOS 5.4, and I have license requests in for Rational Apex and Aonix ObjectAda.
This is a porting effort. The original codebase is Apex 3.0 on OSF1 4.0d.
Anything else I should be considering? Ideally, it would be a supported environment.
One issue you need to take into consideration is to determine to what degree your system that's being ported utilizes vendor-supplied packages to perform its function. What I've seen with older, large systems, especially Apex ones, is a propensity for the language gurus during its development time to have decided that vanilla Ada just wasn't good enough, and so tie into all these vendor-supplied packages. If that's what your system does right now, it's a strong argument for upgrading within the vendor and sticking with Apex (all other things being mostly equal).
Whenever I've done ports of such systems, if given the opportunity I've done my best to tear out all the vendor-supplied stuff--nine times out of ten replacing the vendor-specific stuff with vanilla Ada implementations worked just as well, and you no longer have to deal with the quirks of a compiler-specific package. Plus, you increase the portability and maintainability of the system, allowing it to better adapt to future changes.
There is always SPARK, but I believe its a specialized/subsetted version of the Ada language. You might want to contact SigAda or the Ada usenet group to see if there are any other ideas.
Honestly though, GNAT is a great tool set. You can use GNATBench, an Eclipse interface, or GPS, a light-weight GTK+ IDE, to interface with the GNAT tools.
Other compilers I am aware of are Green Hills AdaMULTI (for various RTOSes), and DDC-I's SCORE (also for various RTOSes)
Providers of certified compilers that support Linux (in addition to those listed in the question):
Irvine Compiler Corp.
OC Systems
RR Software
Sofcheck
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