This document summarizes an embedded software project that used object-oriented modeling and design with UML, along with Safety-Critical Java and C programming. A team of students created a model car that could be remotely controlled via an app. The project followed an object-oriented development process, including use case modeling, component diagrams, and testing of components using mock objects. The design included a layered architecture with hardware abstraction and platform abstraction layers. Missions in Safety-Critical Java were used to model different car modes like Park and Drive. Unit testing of components and testing on the execution platform helped evaluate memory usage and schedulability. The document concludes that this approach helped manage complexity in the embedded system.

1. 1
Embedded Software Development using
UML, Safety-Critical Java, and C
• Background and Objective for the embedded project
• Demonstrator: a Model Car
• Team and method
• Object-oriented steps and diagrams
• Design of system architecture
• Details of some components
• Test of components
• Conclusion
Hans Søndergaard, VIA, hso@via.dk
Together with Ib Havn, Stephan Korsholm, and Christian Sandbeck 21.11.2018

2. • Embedded ICT students at VIA
– First three semesters:
• Using OO-methods and language (Java)
– Fourth semester:
• Difficulty using OO-methods together with C.
Background (1)
2

3. • Embedded Markets Study (2017)
– The debugging process:
• Embedded design team's greatest concerns (23%)
– Greatest technology challenge:
• Managing increases in code complexity and size
– UML
• Only 17% are using UML.
Background (2)
3

4. Demonstrate that
• OO software development with UML can
be used effectively to ensure a better
structure of the software,
• A procedural language (C) along with an
OO language (Safety-Critical Java) can be
integrated easily into the OO development
process.
Objective for the embedded project
4

5. 5
Model car on a track

6. 6
Emulate automat transmission
with four states:
• Park (P)
• Neutral (N)
• Drive (D)
• Reverse (R)
Remote car control:
• App
• Send commands (P, N, D, R, ..)
• Receive messages (speed, ..)

7. Team and method
7
Team:
Covers the different disciplins of
• Hardware and driver design
• HVM (translation from Java to C)
• Safety-Critical Java
• App and Bluetooth.
Familiar with object-oriented
system development and UML.
Method:
Craig Larman’s book.

8. Object-oriented steps and diagrams
8
Requirements => Use case diagram
Analysis => Domain model diagram (classes)
State machine diagram
Design => Component diagram (architecture of system)
Class diagram
Sequence diagram
Implementation => Class diagram
Sequence diagram
Test => Component diagram (architecture of test)
Class diagram.

9. Design of system architecture
9
Embedded systems model Layered architecture
==>

10. HAL and SAL components
10
public class FrontLightImpl
implements FrontLight {
@Override
public void turnOn() {
front_light_turn_on();
front_light_low_beam();
}
...
private native void
front_light_turn_on();
private native void
front_light_low_beam();
...
}

11. Model component
11
States: in SCJ modeled as Missions
• Park => ParkMission
• Neutral => NeutralMission
• ...
Each mission has some handlers.

12. The SCJ Programming Model
12
• An SCJ application is composed of one or more missions
• A mission encapsulates multiple schedulable objects (handlers/threads)
• Types of handlers: periodic, aperiodic, oneshot handlers
• Types of memory: Immortal, Mission, Private with different life times (no GC)
• SCJ programming model: satisfy different requirements as to complexity
• Level 0: cyclic executive with missions that consist of periodic handlers only
• Level 1 and 2: fixed priority pre-emptive scheduler.

13. Periodic event handler in
ParkMission
13
public void handleAsyncEvent() // handler called periodically
{
Mode m = Mode.getMode(commDevice.receive());
switch (m) {
case OFF:
CarSequencer.mode = Mode.OFF;
... // stop engine
Mission.getMission().requestTermination(); // end mission;
// change mode
break;
case NEUTRAL:
CarSequencer.mode = Mode.NEUTRAL;
... // prepare for neutral mode
Mission.getMission().requestTermination(); // end mission;
// change mode
break;
default:
break; // do nothing
}
}

14. Test of components
14
• Passive components => Unit tests
• Active components => Test applications
• Infrastructure components => Test applications + analysis of test results.

15. Test of passive components
15
Unit test of
• methods without native calls => ordinary unit test
• methods with calls of device functions
• using mock objects
• domain code is replaced with dummy implementations
• test of SAL methods without executing on hardware.

16. Test with mock object
16
public class FrontLightTest {
int nativeMethodHasBeenCalled;
@Before
public void setup() {
nativeMethodHasBeenCalled = 0;
}
@Test
public void testTurnOn() {
new MockUp<FrontLightImpl>() {
@Mock
void front_light_turn_on() {
nativeMethodHasBeenCalled++;
}
@Mock
void front_light_low_beam() {
nativeMethodHasBeenCalled++;
}
};
new FrontLightImpl().turnOn();
Assert.assertEquals(2, nativeMethodHasBeenCalled);
}
}

17. Test of active components
17
• An active test class is implemented as a Safelet
• Some of the event handlers use objects with dependencies on external devices
• Fake objects are used to replace objects with external access.

18. Front light fake class
18
public class FakeFrontLight extends FrontLightImpl {
// Override the native methods
@Override
void front_light_turn_on() {
System.out.println("FrontLightFake.front_light_turn_on");
...
}
...
}

19. Test of infrastructure
19
Performed on the execution platform.
SCJ has no garbage collector => predictable execution time
• Handlers each have their own private memory
• Missions each have their own mission memory
• The application has an immortal memory.
Allocation and use of memory must be tested:
ImmortalMem: 16000, used: 13520
MissionMem1: 2000, used: 1122, - maybe reduce size to 1350
PvtMem0: 4000, used 2113, - maybe reduce size to 2540
...
Stack sizes are treated accordingly.
Schedulability test.

20. Conclusion
20
• OO methods with UML can be used with advantage
• A layered architecture and different design patterns help in making
a solution with clean interfaces
• OO modelling with UML and subsequent implementation in C can
be done easily
• The mission concept in SCJ makes it easy to model separate
entities
• a mission encapsulate multiple handlers.
• Missions help to divide the program into smaller and more
manageable parts
• And thus can help solving the problem of handling the increased
complexity of future embedded systems.

21. [1] 2017 Embedded markets study, https://www.embedded.com/, 2017.
[2] T. Noergaard, Embedded Systems Architecture: A Comprehensive Guide for
Engineers and Programmers, Newnes, 2005.
[3] C. Larman, Applying UML and Patterns. An Introduction to Object-Oriented Analysis
and Design and Iterative Development (3rd Edition), Upper Saddle River, NJ, USA:
Prentice Hall PTR, 2004.
[4] S. E. Korsholm, H. Søndergaard and A. P. Ravn, A real-time Java tool chain for
resource constrained platforms, Concurrency and Computation: Practice & Experience,
vol. 2013, pp. 1-25, 9 2013.
[5] The Open Group, Safety-Critical Java Technology Specification, 2017.
[6] B. P. Douglass, UML for the C programming language, IBM, 2009.
[7] JMockit, http://jmockit.github.io/, 2018.
References
21