Autosar -- for software developer - embedded

Can you suggest on this points related to Autosar, taking into consideration I am a software developer who can write some software in C?
Now I Develop a functionality in C, that has to read some ECU specific data, process it & update some ECU specific data (which can be some variable or i/o signal).
Now how I will be using Autosar RTE & virtual functional bus?
What will be there use to a software developer?
Also, as Autosar says "standardization of interfaces" what does it mean? Does it mean that if some else anywhere around the world is also developing same functionality (in C language, like me) we both will be using same name of the API's for those I/O signals?
How RTE will be helpful for me in Unit testing? Or what really RTE is doing from software developer point of view?
http://www.autosar.org/gfx/AUTOSAR_TechnicalOverview_b.jpg
I read a lot technical terms... but being a software developer these points are important for me to know. Can you explain it a bit to me.
Your reply will be appreciated.

I don't think it is going to be that easy...
I believe that you are developing Autosar SWC (software component).
I would recommend for you to develop a portable C module. That has very clear inputs, outputs and req. on execution (check Autosar runnables).
Remember Autosar ECU includes RTOS, therefore your module will be part of a OS task.
When and if you come to the point of building an Autosar ECU, you will be able to wrap the module and connect ins/outs with Autosar virtual functional bus signals. For that you will need Autosar framework and probably configuration tools. These are complex and expensive.
Unit test the module the usual way you test C module.
Good luck.
P.S. RTE is just the "glue" code generated automatically by configuration tools according the configuration of ECU BSW and System Extract for that ECU. You will worry about it during wrapping.

The Idea behind dividing the functionality in AUTOSAR SWC and Basic software is to make the application SW development independent of any platform. To answer your questions.
RTE is giving the application a signal based interface, hence you expect the other SW components (inter-ECU /intra-ECU) to provide the required data in the form of signals, you dont care about the platform or type of communication medium
Yes by standardizing the interfaces (all kind of interactions), a software component or any Basic software module can be Fixed into the SW architecture. Read more about the different type of AUTOSAR interfaces.
Refer to answer 1

RTE is there as a layer to 'abstract' the inner components of the system. For example, if you need to get access to the system's installed flash memory, you have to use the RTE-related memory functions.
You are correct. You only need to read the specifications and use the corresponding functions to get your desired result in an AUTOSAR system.
RTE makes sure that the developers of the software components and the middle-layer systems would work properly with minimal interaction between them. SWC developers just need to read the AUTOSAR standard and follow it to ensure compatibility with the middle-layer systems, since it is expected that the middle-layer system developers would follow that same standard in providing functionalities on their side. It also helps developers with the portability of their software.
I think all your questions can be answered by reading the AUTOSAR standard documents at the AUTOSAR website. Most of my limited knowledge in development of AUTOSAR systems (started reading about it for close to a month already), I got there.

I am a Software developer who Developed a Console Application Tool for Autosar RTE, Test Case Generation for RTE, and wrote Unit Testing Scripts for the tool I created.
I Developed these using C# and NUnit Framework. Same can be Developed using C or a java or any other language. Ultimate goal is to generate AUTOSAR modules (.c and .h files) based on the requirement.
1. Software Developer Scope
As a Software Developer, i had a task to implement complete RTE and Test Applications for the Implemented RTE code.
Inputs and Outputs:
Basically our inputs were Software Component files and ECU Extract which were in ARXML format and Outputs were Rte and test application source and header files (.c and .h) which were created based on the requirements.
Tasks as a developer:
Here, as a developer, we need to perform Input parsing from AXXML to our own data structure, Schema Validation, Modal Validation, File generation etc.
2. Standardization
Yes, AUTOSAR Architecture provides standardized interface. Irrespective of the implementation strategy, API structure remains same which eases the usage. This acts as a generalised library where you can use already developed Module or you can implement the module in your own way by considering API specification. All you need is to follow the specifications provided for every module you use.
Requirement varies from Company to Company but the way of using APIs remains same.
3. Unit Testing
Unit Testing has nothing to do with RTE or AUTOSAR modules. You will be testing the Uints of Your Code. When i say your code, it is the one which you used to develop any particular module (eg. Rte.c) and not testing the generated module itself. You will be testing the Source code you developed to generate the specfic module. Your source code is not part of RTE or any other module implementation but is tool which generates the module implementation.
Overview:
Software developer have various scope in generating AUTOSAR modules depends on the Requirement.
You can develop a tool which will generate AUTOSAR modules.
You can develop an Editor which will is used to edit/create AUTOSAR XML files. (Eg: Artop)
Developing might sound complex as we do not get direct resources other than specifications. Once you are in, you will learn a lot.

To answer your question
If you will go through the Layered Architecture of AUTOSAR, you will come to know this architecture is followed to minimize the dependency of the each module
(layer) with lower layer.
Again, RTE is a like wrapper to separate the lower layered dependency, this enables to work on each layer independently. Most of the virtual buses are mapped with RTE, in my experience I have worked on IOC which is allowed to map with RTE and which communicates with other SWC's with memory and core boudary. To OS Developer its via to the application layer and Mapped software partitions.
The standard is used to maintain uniformation in all software layers, however to meet the requirements the developers may have different way of implementation and design, but the API's and requirements will be universal.
This is useful for standardised intefacing too.
For Unit testing of the developers OS design and implementation RTE works as abstract module.
Reading Specs for different module will resolve most of doubts.

Related

Nontrivial IEC 61131-3 Code Examples

I am currently developing a method for symbolically executing and testing IEC 61131-3 applications.
For evaluating my approach, I require non-trivial programs written in any of the languages defined in the standard.
Are there any openly accessible code bases I could use for this?
The OSCAT libraries is the biggest open code base written in IEC61131-3 afaik. They provide different libraries for different use cases and for different plc vendors
Furthermore there are some example programs available on Beckhoff Infosys. For almost every library they provide a sample section. One of the biggest samples is the OOP extension sample (OOP extensions are included in the new version of IEC61131-3, not sure if you are interested in it).
Another source of examples is the Codesys Store. They have some free and some paid examples.
And one more I like (but its only in german). M. Seitz the author of a good plc programming book provides some accompanying samples, one of them a bit bigger (coffee machine). There is also a simulation and control library available.
A very good source for examples is Beckhoff's information system which is also available for download.
You can find good examples of different methods for example under different libraries.
Some links:
Programming Reference (Good source)
OOP Sample
Standard library (Library containing IEC standard functions)

How to develop many-language / multi-platform lib?

Background: I want to develop a component therefore building a class library.
This component should be usable with many higher-order languages such as C, C#, C++, VB, Java, Haskell, Ruby, Erlang, ...
I do not want to exclude any users which are not using my development language.
Are there principles or tools which supports my project?
I searched a little bit and found Haxle for compiling into different languages, but it supports very few of them.
I would even develop parallel in all n languages to be supported, but if I want to change or fix something I have to maintain all other n-1 and the code is possibly distributed...
This is not what I know about clean code design and maintainability. So how to manage edits on code for the different languages?
What is the proper way to solve this? I am surely not the first one which want to build a library for multiple languages.
I want to develop this library (in this case for complexity reduction) in one target language but this time for multiple platforms (Unix, Win, Mac ...).
How to manage this? In fact there will be appreciated about 90% of code which is platform independent and 10% which differs for every OS.
What is the best way to control the changes in the platform dependent code? (The independent is easy ...)
What if I change so things in the part which uses Unix dependent code, then I have to trail all other platform and the code is possibly distributed.
I think #IFDEF is no option ...
Are there any experiences or hints?
I would be delighted if there are existing solutions to these problems, which are quite similar.
What you want is only possible if you provide interfaces for every language you want to support. Some kind of wrapper which transforms between the client language and ypu library.
This is possible but not practical in most cases for standalone libraries.
Take a look at webservices or or message orientad middleware. In this case your application will be provided within a special container which itself provides interface mechanism e.g.
SOAP, XML-RPC to call your application.
For 1), I would use an interface that all these languages can use. A common approach is something based on networking/TCP, like protobuffer, REST, SOAP. Many languages support these in their standard libraries, and interfaces designed with that are normally language agnostic.
There are basically two options - you could develop a network server or you could develop a JVM-based library which could be shared between some of the JVM languages like JRuby or Jython.
Update from #millimoose: you could also develop your library in C and create bindings for all other languages.
For multi-language:
I thought about TCP/middleware/webservices/REST/ which seems to be the recommended proceeding.
But I think it's all to much at runtime for only using a library.
Also the functionality is a little bit time-critical and so direct procedure calls are more fitting (instead of networking even on localhost). And the library user hasn't to construct an access component only to use the library functions.
So I think the way to go seems to be developing the library in a core language which is widely supported (C/C++, ...) and provide wrapper interfaces for the different target languages.
For multi-platform (mono-language):
No real answer has been provided also not in my mind.
Of course I could simply use Java (what I am familiar with) but what about other languages?
I am surely not the first one having this/these problem(s) ...

API vs Toolkit vs Framework vs Library

My question is very simple, and I want a clear answer with a simple example.
What's the main difference between API, Toolkit, Framework, and Library?
I prefer following:
An API is an abstract description of how to use an application. For example, an API may describe the function syntax (declaration) of a chat server. i.e. login, publish_message, subscribe_messages. And, it describes any protocols to use the application. i.e. must login before sending or recieving messages, or clients are dropped after 2 minutes if not sending or receiving messages.
A library is an implementation of an API, it containes the compiled code that implements the functions and protocols (maintains usage state).
A toolkit is a set of libraries (API) and services grouped together to provide the developer with a wider range of possible solutions. For example, the Globus Toolkit provides services (such as File transfering, Job Subission and Scheduling) that a devleoper can install and start on their servers. They also provide API's to build applications that may use the services deployed in an integrated fashion. For example, the developer may build a program that uses the Job Submission API to communicate with the Job Submission Service.
A Framework is a set of guidelines that prevents inappropriate use or developement. The developer must contruct their applications within the rules and boundaries of the framework. This is done by forcing the developer to extend the current framework to develope new software. by extending the framework, you force adhearence to the framework.
I'm not saying these are completely correct, but its worked ok for me so far!
This has always been my understanding, you will no doubt see differing opinions on the subject:
API (Application Programming Interface) - Allows you to use code in an already functional application in a stand-alone fasion.
Framework - Code that gives you base classes and interfaces for a certain task/application type, usually in the form of a design pattern. (Though not always)
Library - Related code that can be swapped in and out at will to accomplish tasks at a class level
Toolkit - Related code that can be used to accomplish tasks at a component level.
Those terms sometimes are misinterchanged.
Similar posts, read:
What is the major difference between a framework and a toolkit?
Framework vs. Toolkit vs. Library
I prefer to call a library as an alias of module or namespace. Toolkit and A.P.I. is usually a set of libraries for a common task. Altought, A.P.I. is more used for Procedural Programming than Object Oriented Programming.

How hard is it for a .NET programmer to learn Objective C and Cocoa?

I'm trying to build a dual platform application for a company of my own I'm trying to start at night.
I have the .NET version done, but have not finished the UI part. I'm thinking of buying some 3rd party controls.
If I buy these controls, however, they clearly will only work in my Windows version. I'm wondering if I should try to do the UI in GTK# and use Mono with CocoaSharp or just build the thing in MS technology and teach myself the Mac side?
I'm just really unfamiliar with the Mac world and am wondering how much of a learning curve there might be.
I've thought perhaps of rewriting my core logic in Ruby or Python. This why I could use the .NET version with .NET controls and presumably hook the same code up on the Mac.
It's an educational app targeted at consumers. As such, it shouldn't require a lot of technical sophistication to install.
If the non-visual part of the .NET application is quite big compared to the UI, then you can go full .NET and adopt the following two-steps strategy:
Non-Visual Part
Develop the non-visual .NET part to be the most platform independent.
Platform dependent code for non-visual code should be isolated in small classes that provide the same interface so they could be plugged according to the platform.
User Interface
Use System.Windows.Forms (or your favorite toolkit) for Windows
Use a Cocoa bridge (see this page for the choices) for Mac OS X.
You still can benefit from learning Objective-C: as the Cocoa bridges are usually heavily based on the Apple's API, you will find a lot of help in the Apple's sample code (which are in Objective-C).
On Windows, the application will run with the Microsoft .NET runtime and on Mac OS X, the application will run with the Mono runtime.
The DeepMeta application uses this strategy. As you can see the user experience is quite good on both platforms.
Avoid using cross platform UI tools; the result will never be as good as a native implementation, which is especially bad on the OS X where most customers expect a certain level of polish in their applications. Implementing the core logic in a platform independent language like C++ and maintaining a different code base for the interface on each platform can be a good solution, especially if you have a very complex model.
Anyway, you shouldn't have too much difficulty learning Cocoa if you're a good .NET programmer; I did the reverse several years ago and didn't have much trouble. Objective-C is more C oriented than C#, but if you know the basics about pointers and such you're going to be okay. Cocoa and .NET definitely have their differences in certain areas, but they're both high level frameworks which you shouldn't have too much trouble understanding. Get a good book (Hillegass is the go-to author) and go through it so you understand how the two APIs use different design patterns in certain areas, and don't try to fight the framework if it's different than what you're used to.
In my experience this will make you a better programmer in the long run by expanding your knowledge, even if you don't write any more Cocoa applications.

Sharing logic across different platforms

We have a business logic that works with the file systems on OS that we want to implement on both Linux and Windows platforms. The language we have selected is Python for Linux and C# for Windows. GUI is not a priority for now. We were looking for ways to abstract the business logic in a way that we dont have to repeat the business logic (ofcourse I understand since it is related to file system, some code will differ from platform to platform).
Any ideas on how to implement it? Is C/C++ the only option. We dont want to use Java.
Thanks,
Pranz
yea, pick a common language for the logic first. Punting down in to C/C++ pretty much eliminates any of the real values to development that the Python and C# languages provide. Done write, MOST of your logic will be "Business Logic" with the rest glue to external services (i.e. databases, etc.).
So, you should pick a portable environment from the get go. Dropping down to C/C++ and linking it in is a viable alternative, but most likely not worth the time.
Mono is an option you'll probably want to look into.
Quote from the site for easy explanation:
Mono is a software platform designed to allow developers to easily create cross platform applications. Sponsored by Novell, Mono is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime. A growing family of solutions and an active and enthusiastic contributing community is helping position Mono to become the leading choice for development of Linux applications.
Either use Mono or Python.
Mono allows you to run C# .NET code on both platforms. Python can be executed on both platforms already.
Qt has cross-platform libraries for all sorts of things, including UI and file system. It does, however, use C++.