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.
If you like you may
have a look to an example which is called
Visual Instrument.
|
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.
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.
An example of a
generated source code is this
file.
|
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.
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.
|
