Software Project Management

The service includes time planning, the organization of meetings and the regular review of the project plan. Written reports are provided on a weekly and a monthly basis and on your request. Because this service is very much tied to your logistics at least 50 % of the work is conducted on site.

Requirements Specification Evaluation and Editing

Requirements Management is a state of the art procedure at present time. However, to collect all necessary requirements is a very difficult - and boring - task. The service is including interviews with your product managers, developers, quality and logistics people. The final result is a document containing all necessary information and all requirements ready to be included into the data base of project management tools like 'in-Step'.

Firmware and Software Development

The development of firmware and software for embedded systems based on the needs of your logistics, state of the art and your quality aspects and quality control. The following methods were used in some of the past projects: Brain storming, UML modeling, single source databases (also UML based), Embedded C++, coding conventions, MISRA, component oriented design, software reviews, code inspections, file structuring, modular design, object oriented design, run time optimization, timing analyses, case studies.

All activities and implementations are accompanied by a detailed documentation in-source and off-source.

Code inspections

A code inspection is usually a method to improve the quality of your software product. The result of a code inspection is a detailed report. The code inspection can be conducted together with the your team or without.

In case that a piece of software is not well documented a backward verification and a backward documentation can help you to meet your quality standards and to save the value of the software because the value of a software is not presented by the source code but by the documentation.

Windows Software Development

Today it is state of the art to implement application programs in Windows. The preferable base for human interface support is Visual Basic or C#. For the implementation of real time software for testing or for communication C or C++ is the better choice because multithreading is required in most cases.

The development is accompanied by in-source and off-source detailed documentation.

Operating Systems Design

This service can reach from the design of a very small straight forward real kernel, a so called 'event handler' based on a simple timer interrupt up to the integration of an embedded real time operating system such as EmbOS or MicroC OS-II.

This service can reach from the design of a very small straight forward real kernel, a so called 'event handler' based on a simple timer interrupt up to the integration of an embedded real time operating system such as EmbOS or MicroC OS-II.

The most critical issue in most of the embedded systems is the connection to the interrupt system. Therefore usually an analysis is and a documentation taking place before any other activity is started.

Test Development

Sometimes it is the question how to determine the development of a software is finished or not. A test or test sequence has to be designed by defining test cases based on the specification (if existing). The next step is to conduct the test.

The tests can be done manually or automatically. In most cases it has to be preferred to have an automated test running by the control of a PC program. This test can be repeated very easily.

Device Simulation Development

Start to develop the software of your HART device before any piece of hardware exists. Verify the HMI and the behavior of your device on the PC together with your colleagues from marketing. A simulation can also be used for DD development without any hardware because the HART communication is simulated over a com port. You can even do most of HART communication conformance tests in the PC simulation! In addition other aspects of the PC simulation are of interest too.

It is much more convenient to debug a software in Visual Studio instead of debugging it on an emulator system. Therefore state of the art in a lot of development teams is the usage of a PC simulation of the target software within a Visual Studio environment.

The problem for the realization of this is that usually an embedded software is based on a pure C implementation. To connect this C code with Visual Basic, C# or C++ code is the task to be solved.

Another very important aspect is the simulation of the operating system environment. However, some available products like SCIOPTA have already a framework for a PC simulation integrated.

Single Source Development

A very new way to handle parameters in a device is to provide a description of the parameters either in UML or in a database and use this so called single source not only to generate C source code for the handling of the parameters but also to generate DDs for HART, Profibus and FF.

Crashed Software Projects

In many cases software projects are crashing because of two reasons. The first reason is that the task respectively the goal was not defined precisely. The other reason is that the effort was underestimated. In most cases both reasons apply.

The first step is a detailed analysis. The goal or the task for the project have to be defined very well and has to be agreed by the management and the developers. Then an estimate for the effort has to be made and a time schedule have to be defined based on the given resources and their skills. Finally an agreed cost and time estimate is presented as a basis for the decision whether to  restart or to cancel the project.

Embedded Systems Design

At least at the beginning this task cannot be split into a software and a hardware part. In the design phase the optimum system is created and it has to be decided which part can be done in software and which in hardware. Also a lot of influences are resulting in certain requirements: market requirements, user requirements, cost limits, given technology, intrinsic safety (EEx), interfaces, power considerations, form factors, materials and much more.

Device Description Development

Devices designed for HART, Profibus and Fieldbus (FF) need a device description in most cases.x"> The development of a device description is pretty much like software development. Beside the specification of the parameters a menu has to laid out which is conform to the 'state of the art' in which those menus are implemented for existing devices.

Another problem are the dependencies of the parameters. When implementing dependencies the danger is always to get 'circular' situations by accident (e.g. A has to be read before B and B has to be read before A). This 'circular lock' cannot be detected by available tools.

It may be very helpful for a most efficient communication to start with the DD development in parallel to the design of the vendor specific commands. However, as a general rule it can be stated that is is the best way to always read large groups of parameters but to write them as singles or in very small groups.