Choice of Platform

prettybadelyngeSoftware and s/w Development

Nov 18, 2013 (3 years and 6 months ago)

89 views






STWW
-
Programma


SEESCOA:

Software Engineering for Embedded Systems
using a Component
-
Oriented Approach







Choice of Platform












SEESCOA PROJECT


Choice of platform




1










Contents

CONTENTS

................................
................................
................................
..................

1

INTRODUCTION

................................
................................
................................
..........

2

PLATFORM REQUIREMENT
S

................................
................................
...................

3

IMPLICATIONS FOR THE

WORK PROGRAM

................................
.........................

4

COMMON PREJUDICES

................................
................................
............................

5

Java is too slow

................................
................................
................................
................................
..............................

5

Java is not suitable for hard real
-
time systems

................................
................................
................................
........

5

Java requires extra memory

................................
................................
................................
................................
.......

5

We can do better in C or C++

................................
................................
................................
................................
.....

6

HARDWARE

................................
................................
................................
................

7

REPORTED PROBLEM ARE
AS

................................
................................
................

8

CONCLUSION

................................
................................
................................
...........

10

APPENDIX: PROCESSOR
BOARDS

................................
................................
......

11


SEESCOA PROJECT


Choice of platform




2










Introduction

This document reports on task 1.4: Choice of common platform. The objective of
this
task is to choose the platform, programming language and tools to be used by all
partners, for development of tools on the one hand, and for the realization of the
common test case on the other hand. To guarantee that intermediate outcomes can
be exch
anged and that all results can be seamlessly integrated it is important that all
partners work in similar environments.


SEESCOA PROJECT


Choice of platform




3










Platform requirements

Given the case we want to implement, and the work program of the project, the
chosen platform should




enable our

component model



support (soft) real
-
time constraints



allow for a high software productivity



preferably be an open standard and have well
-
defined APIs



support remote connectivity



support user interfaces



must enable reuse and portability



run on an off
-
the
-
self hardware platform


Based on these requirements, a survey of existing platforms, the description of the
systems used in the companies, and the available expertise in the consortium, we
have decided to use Java. We believe that Java has many advantages
for the
development of embedded systems:




Java is an open standard



Java is a pure object
-
oriented language



Many open source libraries are available



Many services are for free (TCP/IP, multi
-
threading, …)



Java has a higher software productivity due to a hi
gher abstraction level



Java is promising technology for embedded systems.


Java needs a virtual machine to execute. This virtual machine




Shields the underlying hardware architecture



Is available for a wide range of hardware platforms:

o

standard edition (d
esktop platform)

o

enterprise edition (server platform)

o

micro edition (embedded platform; Javacard)



Has kernel functionality or can be run on top of a real
-
time operating system



Allows access to hardware by means of native routines


SEESCOA PROJECT


Choice of platform




4










Implications for the work

program

The
design methodology

is not fixed yet, but it is clear that it should support object
-
orientation, and that it should also support iterative development, which is considered
important for the development of embedded systems. It will probably be b
ased on
UML extended with real
-
time capabilities. We will also look into the possibility for
hardware/software codesign.


The
component architecture
we propose will benefit from Java as programming
language. Java allows defining components and interfaces.
Java even allows
replacing components dynamically, which means that we will be able to construct a
sophisticated component system.


The
debugging

tasks will also benefit from Java as platform. There is a clear
separation between the Java and JVM level, whi
ch has many advantages. Low level
debugging is fairly straightforward to implement because Java byte code is executed
by the Java virtual machine, and hence it can be instrumented in software.
Furthermore, Java has no explicit pointers, and thus, in theory
, it does not have
memory leaks. Many error conditions are taken care of by exception handlers, which
improves the observability.


With respect to
user interfaces
, Java has its own GUI
-
libraries (with adaptable look
-
and
-
feel), and remote user interfaces (s
ervice interfaces) are easy to realize thanks
to the Internet connectivity.


SEESCOA PROJECT


Choice of platform




5










Common prejudices

There are four common prejudices against using Java for the development of
embedded systems.


Java is too slow

We believe that Java is fast enough for our applic
ation, provided that we use it in the
proper way, and avoid the use of notably slow features. Furthermore, when needed,
applications can be made faster by




Statically linking the application



Compiling the application when downloading it



Controlling the gar
bage collector



Calling the proper Java low level methods



Calling native C routines where necessary


Java is not suitable for hard real
-
time systems

This is mainly due to the garbage collector. There exist however solutions for the
problems caused by the g
arbage collector.


E.g., JBED is a real
-
time operating system and embedded Java virtual machine,
suited for hard real
-
time applications. It has a very small footprint, compiles Java to
native code, uses a hard real
-
time garbage collector (never delays real
-
time tasks),
and a hard real
-
time task scheduler (Earliest Deadline First). Even device drivers can
be written in Java (http://www.oberon.ch/rtos).


Another possibility is to run JVM on top of a standard real
-
time kernel, and to
implement the hard real
-
ti
me code in the traditional way as a task in the real
-
time
kernel. The JVM is then implemented as a low priority task.


Java requires extra memory

A complete JVM can take as much as 1 MB of memory. For small systems there
exist smaller alternatives (< 200 k
B), and the K virtual machine of SUN requires only
40 kB. It is however clear that the virtual machine can only be made smaller by
removing functionality. Furthermore, the memory overhead is not limited to the JVM.
Java is known to allocate many (extra) ma
nagement objects to support its operation.
The kinds of applications we envision in this project do not have strict memory
SEESCOA PROJECT


Choice of platform




6










constraints, which means that there are resources available to run the Java virtual
machine, and pay the overhead of the extra object
s.



We can do better in C or C++

Isn’t this a similar argument as C/ASM debate of so many years ago?



SEESCOA PROJECT


Choice of platform




7










Hardware

For the hardware, we will use an off
-
the
-
shelf processor board with Ethernet
connectivity, ROM, Flash, RAM, an interface to the camera (USB or
Video signal),
and a small LCD
-
display. We prefer a 32
-
bit processor. Appendix A contains a
survey of existing processing boards.

SEESCOA PROJECT


Choice of platform




8










Reported problem areas

In the summarizing report on the visits, there is a list of reported problem areas
identified by the co
mpanies of the industrial partners. We believe that our choice for
the Java platform can help in solving some of the problem areas too.


1.

Integration of third party software:
integrating the JVM can still pose problems,
but once the JVM is running (and pas
ses all the standard tests), integrating Java
code should not pose big problems as the JVM should execute them without
major problems. Porting the JVM might also be easier since it is the same
software that has to be ported over and over again, and a team
can build up
experience.

2.

Generation and maintenance of documentation:
JavaDoc can help in maintaining
documentation on the Java code. It isn’t however the ultimate tool for managing
documentation.

3.

Debugging: memory leaks, ISR:
Java does not have pointers,
Java type memory
leaks can still exist (by not releasing all references to an object). ISRs can
sometimes be written in Java, which makes them better observable.

4.

Lack of multi
-
platform IDE, tools:
there is only one target platform left, namely the
Java pla
tform. Cross
-
development is for free as any Java development
environment should do the job.

5.

Effort estimation techniques (metrics):
it is not clear whether Java offers benefits
at this point.

6.

Performance estimation techniques:
it is not clear whether Java

offers benefits at
this point.

7.

Hardware problems:
they are easier to trace. A bug in the Java code will
generate an exception, while a bug in the JVM might cause a crash of the
program. Furthermore, bugs in the JVM are unlikely to occur after a standard
set
of benchmarks has been tested.

8.

Changing requirements:
by using an incremental software development
methodology, combined with an object
-
oriented programming language and
components, we should be able to adequately deal with changing requirements.

9.

Lack

of qualified personnel:
the Java platform is a standard platform that is
understood by an increasing number of developers. Since the hardware is
shielded, people that are not familiar with computer hardware can also contribute
to the development of embedd
ed systems.

10.

Serviceability:
remote access to a networked Java
-
based embedded system
almost comes for free, while not neglecting issues like security.

11.

Growing complexity of software:
the use of an object oriented programming
language and components certainl
y helps in alleviating this problem
.

12.

Low software productivity:
Java is known for its higher software productivity
.

SEESCOA PROJECT


Choice of platform




9










13.

Need for rapid prototyping:
Java allows to quickly building a prototype.

14.

User interface specification is difficult:
Java supports building p
latform
-
independent graphical user interfaces.

15.

Testing is time
-
consuming.
This is independent of the platform chosen
.

16.

Multi
-
site development:
idem.

17.

Versioning of the design:
idem
.

18.

Deadlines:
idem
.


SEESCOA PROJECT


Choice of platform




10










Conclusion

We have chosen to use the Java platform to impl
ement our case study. We believe
that Java will enable us to

1.

successfully implement our case,

2.

carry out the work program as described in the proposal,

and that Java can also be a solution for some of the problems that were identified by
the companies duri
ng our visits.

SEESCOA PROJECT


Choice of platform




11










Appendix: processor boards