Sticky Bits

I would like to apologise about the lack of posting in the last couple of months. Unfortunately due to an unprecedented workload both Glennan and myself have been pretty much maxed out, meaning we have neglected the blog. I’m hoping we can remedy this very soon; not due to a lower workloads but as we are recruiting to expand the Technical team here at Feabhas (if this may be of interest please feel free to contact me via LinkedIn or directly).

Thanks for all your great feedback and words of encouragement regarding the blog.

Niall.

What is Configuration Management?

Configuration Management has its roots in the US Department of Defence in the 1950’s. It started as a technical management discipline and has been widely adopted by many other engineering disciplines, including Systems Engineering and Software Engineering. Configuration Management focuses on establishing, and maintaining, the consistency of a system or product throughout its lifetime. CM is a collection of competencies, techniques and tools whose purpose is to ensure the consistency of the system’s requirements, functional attributes and physical properties.

For the purposes of this paper we shall consider four fundamental, inter-related activities:

Revision Control

Revision control is concerned with controlling access to project artefacts and maintaining a history of changes to each artefact.

Configuration Identification

Before you can control any artefact you must identify what it is, what information it is going to contain and how it will be controlled.

Change Management

When an artefact has to change, Change Management controls when, or even if, the changes may be performed.

Release Management

Release Management focuses on the delivery of software outside the development department.

These activities are inter-related and highly dependent on each other.

 

Why perform CM?

Good Configuration Management ensures that the current design and build state of the system is known and recorded; and doesn’t rely on the tacit knowledge of the development team.

Being about to access an accurate historical record of system development is very useful – not only for project management and audit purposes, but for development activities such as debugging (for example, knowing what has changed between one set of tests and the next to help identify what could possibly be causing a fault).

Effective use of CM tools enables engineers to formally (and safely) record all change details. In particular, not only what was changed in the product but why it was changed

CM ensures that documentation can be produced which truly describes delivered systems.

Sometimes, it is necessary to rebuild old versions of products to reproduces problems for customers, such as the military, haven’t upgraded their tools to the latest versions.

Finally, and not to be overlooked (since these things happen!) good CM practices enable a system to be rebuilt correctly in the event of mistakes, failures and catastrophes.

 

Getting CM wrong

Configuration management can seem an awful lot of effort, much of which appears to be an overhead on the development of software. However, getting CM wrong can lead to the following:

– The wrong requirements being accepted

– The wrong design being implemented

– The wrong tools being used for development

– The wrong software being tested

– The wrong test suite being used

– The wrong version of software being released

Any of these could lead to huge amounts of wasted effort, wasted money, late deliveries and seriously dissatisfied customers. It doesn’t matter how good the software is, delivering the wrong product is never going to win you any plaudits.

RULE 8: Don’t describe the user interface

For many users the user interface is the system.  Prototypes and mock-ups of the man-machine interface (MMI) are a fantastic way of eliciting requirements and use case behaviours from your stakeholders.  And when defining use case descriptions adding MMI ‘screenshots’ and images can help illuminate the behaviour of the system to your customers.

 

It is very tempting to describe use case transactions in terms of MMI elements, in an attempt to make them more understandable to the customer.  However, be aware: this is a very high maintenance solution.  The one thing that can almost be guaranteed in the design of any system is that the MMI will change.  A lot.  By writing your use case descriptions in terms of user interface elements you will be constantly going back and revising your use case text (and reviewing, and doing impact analysis… you do these, don’t you?!)

To minimise the maintenance effort of a regularly-changing user interface we must uncouple the user interface from the functionality of the system.  We must separate the effects of information flowing into and out of the system – What the information content is and how the system responds to it – from the presentation of that information to the user.

The use case description defines the desired requests and responses to the system; the MMI defines how those requests and response are manifested.

An event-mapping table can be used to map functions of the MMI (or indeed any interface specification) to the system event (transaction) it invokes or is in response to.  Using an event-mapping table de-couples the interface from its function. 

 

Events are typically one of the following:

COMMAND
A control input to the system
Used to control the behaviour of the system

INPUT
Normally represent a change in the environment
May be an analog or digital signal
The system may or may not respond to the change

OUTPUT
A signal to the environment from the system
Used to effect changes in the environment
May be an analog or digital signal

STATUS
Feedback data from the system
Contains information about the current system state

The mapping table allocates some user interface operation (which could be as simple as a drop-list selection, or as complex as a whole sequence of button pushes or mouse clicks) onto a system behaviour.

In our simple example, pushing the big green button is our UI action.  We’ve mapped this onto the ‘START SYSTEM’ command.  Similarly, when the system is ready, this ‘READY’ status event is mapped onto the illumination of the LED.  Now, if the user decides they don’t want a ‘ready’ LED but instead want a 16 x 2 character display, we can simply re-map the ‘READY’ status event onto a displayed message (something creative like "System Ready")

In this way you only need to change the use case description when the functionality of the system changes (hopefully, far less often than the MMI!)

Doing this separation also alleviates that all-to-common problem of poorly-written requirement specifications: the User Interface Specification contains half the functional behaviour of the system; and the System Requirements Specification contains half the user interface detail!

 

<<Prev     Next>>

RULE 4 : The “Famous Five” of requirements modelling

As I discussed in Rule 1, a common misunderstanding of use cases is that they are the software requirements. Unfortunately, this isn’t the situation. Use cases are merely an analysis tool – albeit a very powerful tool (when used in the right situation).

Use cases are just one technique for understanding and analysing the requirements. In order to fully understand the requirements our use cases are going to need some support. Use cases are just one of my “Famous Five” of requirements analysis models.

The Requirements models are:

• The Use Case model
• The System Modes model
• The Context model
• The Domain model
• The Behaviour model

Why five models? Well, each one tells me about a different aspect of the system. No one point of view can tell me everything I need to know in order to ensure my requirements are coherent, consistent and unambiguous.


The Use Case model is focussed on interaction behaviour: the who, how, what and when of interaction between the stakeholders and the system.
Use cases focus on operational scenarios. For some systems (especially a lot of application software) the (transactional) exchange of information between the users, or other direct interactors, and the system forms the bulk of the software functional requirements.
However, many embedded systems are not user-centric, or transactional in their behaviour (for example, a closed-loop control mechanism). Anyone who has attempted use case analysis on such systems tends to find the use case model is non-intuitive to construct; and tends not to yield very much information about the behaviour of the software.

The System Modes model defines the temporal behaviour of the system. That is, how the behaviour of the system changes of time, in response to external (and internal) stimuli.
The System Modes model allows the analyst to capture when and how the system functionality is available. The System Modes model is a declarative diagram, showing the behavioural modes of the system (without saying how the behaviour will be enacted) and the signals or events that cause the behaviour to change.
Application software may not be modal: it’s either running or it’s not. Embedded systems tend to have more complex dynamics (I see the system dynamics as one of the big differentiators between embedded software and application software). There are typically states where the system’s primary functionality is available, and other states where it is not. For example, most embedded systems cannot provide their primary functionality when they are starting up, or shutting down, or in a maintenance mode.

The Context model defines the physical scope of the system: what is part of the system (under your control) and what is external to the system.
When creating requirements it is vital to separate the Problem Domain (the part of the real world where the computer is to exert effects) from the Solution Domain (the computer and its software). In fact, requirements should be describe in terms of the effects the system should exert in the Problem Domain (rather than how it should be designed). In addition there must be specifications for what are called Connecting Domains – that is, how the system’s input/output devices must behave (interface specifications).
The Context model gives a clear visual delineation of the Problem Domain (the environment), the Solution Domain and the Connecting Domains. The software is treated as a single black-box entity. The environment consists of the Direct Interactor stakeholders. Each Stakeholder interacts with the system via one or more interfaces (often called Terminators). For each element on the Context model there should be a set of requirements. In this example I have simulated a Context Model using a SysML Internal Block diagram.

The Domain model focuses on the information (that is, data) in the system and, more importantly, the relationship between the information.
The domain model aids with building a project ‘glossary’. In any project there is a huge amount of tacit information about how the problem domain operates, and the language that is used to describe it.
The focus of the Domain model is understanding the problem and describing it, rather than specifying the problem’s solution. Typically, a form of entity-relationship diagram is used. With UML, a class diagram is used (or a Block Definition Diagram in SysML).
It is tempting for development teams to skip this stage; the argument being “well, everybody knows this!” By actively and coherently modelling this information you may well avoid implicit misunderstandings; that can cost a project dear, if found too late.

The Behavioural model captures the transformational aspects of the problem. The Behavioural model focuses on sources and sinks of information, and what transformations are performed by the system in between.
Although ultimately all software behaviour comes down to executing imperative code, this should be avoided for requirements analysis. Rather, focus on declarative statements of behaviour and where the data comes from (and goes to) rather than how the algorithms will be implemented.




The great strength of producing multiple models of the same system is that they are self-validating. Building a consistent set of models gives confidence that the analyst has truly understood the problem.
Concepts defined in one model must not conflict with the same concept in another model. For example, stakeholders defined in the Use Case model (its actors) must also appear on the Context model (otherwise, how are they interfacing to the system?!); similarly, the Use Case model should not mention any data or information that is not captured on the Domain model.
As I wrote in Rule 1, systems tend to have a predominant characteristic – that is, they will either be a Modal problem, a Transactional problem, a Flow-of-materials problem or a Data-Driven problem. When you are building your models of the system one or two diagrams will tend to give you more information than any of the others. For example, in a data-driven problem the Domain model will probably give you more information about the behaviour of the system than, say, the Modes model or Use Case model. The table below gives an indication of the relative value of each of the models.

<<Prev     Next>>

At Embedded Live 2010 I shall be presenting a half-day tutorial entitled “EMBEDDED PROGRAMMERS’ GUIDE TO THE ARM CORTEX-M ARCHITECTURE”.

Feabhas have been training embedded software engineers in languages and architectures for the last 15 years. For the last decade we have been using ARM based target systems for all our programming based courses (C, C++ and testing – ARM7TDMI) and embedded Linux courses (ARM926). However with the development and release of the new generation Cortex micros we are moving our training over to Cortex-M for the languages and Cortex-A for Linux.

As part of this exercise we have to spend lots of time getting to know the Cortex microprocessors in detail, looking at different implementations and various support tools and environments.

The majority of supporting material around the new generation of ARM Cortex-M architectures (M0, M3 & M4), unsurprisingly, focuses heavily on the key hardware specifics of the microcontroller core, with most coding examples being in THUMB2 assembler. However the majority of programming for the Cortex will be in the C programming language (recently a VDC report showed C is still head-and-shoulders above other languages for embedded programming )

Core Features

This class looks at all the really useful features added to the Cortex-M that makes it a truly excellent target environment for the embedded software engineer.  As a simple example many embedded processors do not support integer division in hardware (e.g. ARM7), so division typically handled by an intrinsic library function call or compiler ‘tricks’

The new Cortex-M3 has new signed and unsigned integer division instructions, that can also support modulo operation ( x % y )

There are many other features that I shall cover including unaligned-transfers, bit-banding and the new improved interrupt support architecture (NVIC).

However, there are three other significant supporting technologies that really help the software engineer.

1. Cortex Microcontroller Software Interface Standard (CMSIS)
2. Debug Support
3. RTOS Support

CMSIS

Simply put, CMSIS is a collection of source files (.c, .h and assembler) to create a minimal board support package (BSP) for Cortex-M series processors. Very usefully, it defines a common way to access peripheral registers and define exception vectors. It also defines the register names of the Core Peripherals and the names of the Core Exception Vectors. So, instead of having to spend time and effort defining structs for register definitions for onboard devices (or hoping you development environment has already done this for you) you can be assured that they already exist. For example, the NXP LPC17xx family of microcontrollers support a watchdog timer. Being CMSIS compliant, then the supplied header LPC17xx.h defines the register layout and necessary #defines:

Debug Support

JTAG units, such as the Keil ULINK, have made target programming and source-level debug very affordable. However, for small pin count micros, the 4-wire JTAG is seen as quite expensive option (in terms of pure pin-count). As part of the Cortex-M core is support for a new serial-wire interface. The advantage being that it only requires 2-wires, which makes it very easy and affordable to support debug (and power) over a simple USB connection.

At the other end of the spectrum, ARM have added the option for an Embedded Trace Macro (ETM) unit, which allows features such as debug of events in real-time systems where the target cannot be halted and software profiling and code coverage.

RTOS Support

For someone who has a long background in Real-Time Operating Systems, I was very interested to discover how ARM has made it simpler and easier for an RTOS vendor to support the Cortex-M.  As you can guess CMSIS is a huge step forward, as it means once an RTOS has been ported using CMSIS, the core aspects will work on, say, all Cortex-M3 implementations.

As a simple example, pretty much all RTOS require a time-frame reference (the “tick” timer) for timeouts and delays, etc.  ARM has integrated this directly into the core (called Systick) rather than each silicon vendor having to implement their own count-up or count-down variant. There are already 20+ RTOSs running on the Cortex-M.

Also as, as an optional part of the Cortex-M3/M4 core is a memory-protection unit. An RTOS can make use of this to create a safer multitasking platform without the expense of a full-blow MMU.

Finally, what makes the Cortex-M so attractive from a embedded software engineers perspective is to abundance of low cost evaluation kit, such as mbed, LPCXpresso, STM32 Value line Discovery, Energy Micro Gecko Starter Kit, and Actel’s  SmartFusion to name just a small selection.

I hope to see you at Embedded Live 2010. If so please come and say hello.

This the headline to the central story in today’s New York Times. The story is about the overuse of PowerPoint by the US military, especially in Afghanistan. It centers around a particular PowerPoint slide (shown below) attempting to portray the complexity of US strategy in the region.

The article discusses that a Brig. Gen. H. R. McMaster banned PowerPoint presentations when he led the successful effort to secure the northern Iraq city of Tal Afar.

Leading on from this,  you may be aware, that next weeks UK event the Embedded Masterclass has also banned PowerPoint from its technical presentations. To quote from the website:

This year we have asked the presenters of the 40 min Technical Presentations to ‘abandon Power Point’ . Instead they will have a white board, a flip chart and hand-outs and of course – their wit and charm ! We want to bring a bit of life back into these kinds of events and raise the standards. We are hoping this will lead to a better and more inter-active presentation. It is already causing the presenters to think more carefully about what they intend to present and how it will be structured.

I understand the sentiment, but I’m sorry but No; PowerPoint is just a tool. Banning (or abandoning) PowerPoint is not addressing the root problem.

For anyone who wants to do a professional job of presenting then there are great reference materials out there (e.g. Presentation Zen, silde:ology, beyond bullet points, etc.).

In reality many poor presentations are due to a lack of a proper review process prior to the event(admittedly some people just can’t present). All presentations should be backed up by a hand-out technical paper and not just a print-out of the slides (eliminating the need for lots of technical detail on a slides). Finally, being someone who has to regularly present  5 days of detailed technical training on embedded systems, white boards and flip charts just aren’t big enough for a large audience (unless you can write REALLY BIG).

To combat this problem of free form notes to a large audience, at Feabhas we have been using a really cool tool called PaperShow to augment the slides. Ideally we’d use two projectors, but this isn’t typically practical. Alternatively you could go back to the “good old days” on OHPs, foils and pens.

As I’ll be at the Cambridge event (as we’re running an Embedded Linux training class) I’m really interested in how it actually works and my concerns will hopefully be proven wrong. Hopefully see you there…

As I’m sure you’re well aware, the ash cloud from the Eyjafjallajokull volcano (which began erupting in mid-March) pretty much brought much of European airspace to a standstill over last weekend and into this week. Now that UK airspace has been reopened, it appears I can resume plans for my visit to the Embedded Systems Conference in San Jose next week.

The sessions I’m directly involved with are:

Examining ARM’s Cortex Microcontroller Software Interface Standard – CMSIS
Date/Time: Tuesday (April 27, 2010)   3:15pm — 4:15pm
In this session I shall be examining ARM’s Cortex Microcontroller Software Interface Standard (CMSIS -  typically pronounced C-M-Sis) . CMSIS aims to provide a framework of reusable components for software developers, silicon and compiler vendors to utilize. Aspects such a power-up boot management and interrupt control have been abstracted and defined by ARM for their Cortex-M family of microcontroller cores. I’ll spend time explaining the CMSIS framework, examining the code from a compiler and chip perspective, and finish off by discussing the pros and cons I see in such an approach.

Understanding Mutual Exclusion: The Semaphores vs. the Mutex
Date/Time: Wednesday (April 28, 2010)   12:00pm — 12:50pm
Location (room): ESC Theater 2
This presentation is based around much of the material in some of my previous postings (see RTOS related blog postings ). One of the things I like about ESC events is that some of the sessions are free. So if you happen to be attending just the exhibition, then you can still attend this session.

The State of Embedded
Date/Time: Wednesday (April 28, 2010)   4:00pm — 4:50pm
Location (room): ESC Theater 1
Finally, I have been invited to participate in an informal session along with Jack Ganssle and Dan Saks (moderated by Rich Nass of Embedded.com and EE Times) to discuss some of the latest trends in embedded systems. We did a similar session at ESC UK back October 2009, which was very well received. It shall be interested to see how being the token European with a US audience differs from the UK event. This is also a free session.

If you’re at the event look me up and say hello.

Over many years of delivering technical training to the embedded systems sector, two questions have always bothered me:

• Why, when the economy gets difficult, are training budgets one of the first things to get cut?
• Why do delegates, who have waited months (sometimes years) to attend training, get pulled off mid-course?

Even though a myriad of articles tell us why businesses should invest in training during an economical downturn (Why Invest in Training During an Economical Downturn?) funding for training is very hard to come by. So why does this happen?

In reality there are only two types of training:

• Must-do
• Everything-else

Read more »

After not too much of a learning curve we’ve migrated the website to support wordpress and the associated tools (SQL, PHP, etc.). After checking everything was fine and giving the go ahead for the “go live” for some reason it’s lost the links to all the diagrams from the posts! So I’ll be retrofitting the diagrams over the next week.

First impressions, WordPress is a wonderful leap forward from blogger.

Next post: reflections from embedded world 2010.

Unfortunately Google (via blogger.com) have announced that as of the 26th March 2010 they will discontinue support for FTP uploads from blogger accounts. Current the Feabhas blog is created and managed from blogger but uploaded to our Feabhas server. So having really just got my head around blogging it’s got to be all change. We have a number of posts to publish (including my trip report to embedded world 2010), but I plan to hold off until we have resolved the best route forward (ideally wordpress) . I’m hoping it has no impact on the atom feed, but only time will tell. Watch this space…