This document summarizes the key aspects of developing and maintaining BGAN waveform software from a supplier's perspective. It discusses licensing over 82,000 units, the typical development process involving knowledge transfer, platform porting and approval testing. It outlines challenges including diverse architectures, compilers and operating systems. It emphasizes the importance of well-defined and minimal dependencies without cycles. It provides lessons learned around interface design, anticipating future changes, and ensuring refactoring is possible without breaking existing functionality.

1. Slide 1
SOFTWARE-GENBRUG
- fra en leverandørs synspunkt
December
2017

2. Slide 2
BGAN Products with Licensed GateHouse IP
82,000+ licensed units

3. Slide 3
BGAN Waveform Components
L-band Antenna
RF
Application Framework
Customer Applications
Interfaces
Protocol Stack
Physical Layer
Satellite Terminal
1. Contains 3 independent components
2. Can be licensed individually
3. The Protocol Stack is a de facto standard
GateHouse Waveform

4. Slide 4
Typical Terminal Development Process
Knowledge Transfer
• Product design and program planning
• Exchange of documentation
• Training
Platform Porting & Optimization
• Delivery of platform to GateHouse
• Interface code modifications
• Build of software for target platform
• BGAN waveform pre-release
Approval Testing
• Inmarsat MTR
• BGAN Network Emulator
• On air testing
Inmarsat FTA
Time
1-2 months
3-6 months
4-8 months
8-16 months

5. Slide 5
Setup & Drivers
InmarsatGateHouse
Manufacturers
Specification
Test
Requirements
System
Changes
Support &
Maintenance
Type Approval
Project
Milestones

6. Slide 6
Development & Maintenance
• System Definition Manual (Protocol Specification)
– Updates 1-2 times a year
– Major additions every ~4 years
• Manufacturer requirements & milestones
– Product launch milestones
– Requirements conflicting with specifications
– Customer-specific workarounds
• Manufacturer maintenance constraints
– Reluctance to upgrade to latest
– Aero requirements (DO-178b)
– Refactoring is frowned upon

7. Slide 7
Legal Challenges
• Open Source Clauses
– “No 3rd party software” (unless agreed in contract)
• Qualification & Certification
– DO-178 (Airborne Systems)
– Or... MISRA
• Export control
– Encryption

8. Slide 10
Software “Reuse” For Us
• Functionality is obviously reusable
– 90% of core stack is the same despite product differentiation
– 10% is market-sector/feature-specific (maritime, aero, safety)
• More than ‘inheriting software packages’
– Maintain core library across diverse set of projects & milestones
• Challenges
– Diverse architectures, compilers, operating systems
– Parallel feature development & maintenance
– Products & launch schedules

9. Slide 11
Challenges: Architectures
• ARM
– multiple versions & manufacturers
• PowerPC
• i386
• As low as (2004):
– 50 MHz
– 32 MB RAM
– 16 kB data cache, 16 kB instruction cache
• Problem areas
– Code size (and effect on caching)
– Data copying
– Levels of indirection
– Stack initially developed on PC

10. Slide 12
Challenges: Operating Systems
• Embedded
– VxWorks
– QNX
– Nucleus
– Integrity
– (Linux)
• PC
– Windows
– Linux
• Memory management
• Threading/tasking, pre-emption

11. Slide 13
OS Interfaces
• Primitive wrappers for:
– Mutex (Re-entrant)
– Thread (Pre-emptive)
– Semaphore
– Memory management
– (IP Stack)
• None of these:
– Filesystem
– Message passing
• NV-MEM, Logging

12. Slide 14
Challenges: Compilers
• Visual C++
• GCC
– 2.96 (17+ year old, bastard version by Windriver)
• Poor C++03 support
• Poor optimization for ARM
– GCC 3.3 (12 years old as of 2017)
– GCC latest-and-greatest
• Warnings
• Green Hills Integrity
• armcc

13. Slide 15
Challenges: Build Systems
1. Previously:
1. Visual Studio solutions (in version control)
2. Hand-written Makefiles
3. Attempts at “generic” Makefiles
4. Others: Eclipse/Green Hills
2. Today:
1. CMake
2. Target-specific Makefiles
3. Tool-specific “solution/project” files (e.g. Green Hills)
3. Rules:
1. No cyclic link-time dependencies!
2. No cyclic compile-time dependencies (includes) (Sadly not 100%)
3. Include what you need, and only what you need

14. Slide 16
Challenges: Multiple Development Tracks
Baseline
BGAN-X
HDR/LDR
1.x
2.x
3.0
3.1
3.2
2.4
3.0
MSDS
2002 2004 2010 2017
SB-SAT
3.x-SB-SAT
2.x-SB-SAT
SB-SAFETY
2.4-customer1 2.4-customer2
2012

15. Slide 17
Development Process
• Software style guide
• Implemented in C++ (subset)
– Restricted use of standard library (vector, list, map, queue is OK)
• Unit tests of low-level functionality
• System-level test of high-level functionality
• Every change (bugfix, features) implemented on a branch
– Code review, test before merge
– Build server:
• Builds with several compiler versions (-Wall -Wextra -Werror -pedantic)
• Runs unit tests
• Checks code style
• Changes selectively merged as a part of the release process

16. Slide 18
Change Control
Coding begins
Acceptable number
ofWTFs
Change is merged
to baseline / Patch prepared
Too many WTFs
It s a bug
It s a
feature
New issueis filed
New Rejected
Accepted
In Progress
Approved
Feedback
Testing
Verified
Test passes
Closed
Software released
Test
fails
Assign issue to person
responsible for implementing
thechange
Assign issue to person
responsible for reviewing the
change
Assign issue to person
responsible for testing the
change
Fix is committed
Ready for review
Coding begins
Acceptable number
ofWTFs
Too many WTFs
It s a bug
It s a
feature
New issueis filed
New Rejected
Accepted
In Progress
Approved
Feedback
Test
fails
Assign issue to person
responsible for implementing
thechange
Assign issue to person
responsible for reviewing the
change
Fix is committed
Ready for review
Coding begins
Acceptable number
ofWTFs
Change is merged
to baseline / Patch prepared
Too many WTFs
In Progress
Approved
Feedback
Testing
Verified
Test passes
Closed
Software released
Test
fails
Assign issue to person
responsible for implementing
thechange
Assign issue to person
responsible for reviewing the
change
Assign issue to person
responsible for testing the
change
Fix is committed
Ready for review

17. Slide 19
Lessons from Mistakes - Dependencies
• Dependencies
– well defined
– minimal
– strict
– non-cyclic
• Types of dependencies
– Link time dependencies (libraries)
– Compile-time (includes)

18. Slide 20
Lessons from mistakes 2 – Interface Design
1. Interface Design Anti-patterns
1. Design-by-legacy:
1. Designed in cooperation with user (Affected by user’s legacy)
2. Not prepared for other user’s legacy
2. Complexity exclusion:
1. Move complexity to user side of interface
2. Great effort on user, requiring domain knowledge
2. Choose two:
1. Quick to develop
2. Easy to understand & use
3. Generic enough for multiple use cases

19. Slide 21
Lessons from mistakes 3 – Plan for change
“We don’t break user space”
- Linus Torvalds
1. Evaluate every design decision:
1. Is there a risk we will need to change this?
2. Will is be possible to change this? What will the approach be?
3. Can I make the change now so I wont have to later?
4. Can the design be made orthogonal to future changes?
2. It can be the simplest of things:
1. Coding style that won’t work on a future platform (e.g. use of uintX_t, size_t)
2. Code clean-ups/trivial refactoring
3. Directory structure
4. Include hierarchy

20. Slide 22
OUR EXPERTISE. YOUR GAIN.
Thank you
for your time!
Thank you
for your time!
Thank you
for your time!