Developing an Open Source Satellite requires open thinking

It’s not often that engineers are given the opportunity to start with a truly clean sheet of paper and have a remit to actively challenge the mindset of “we've always done it this way” when undertaking design work.  This makes the development of the Open Source Satellite a really exciting prospect.  This excitement is tempered by our awareness that care will need to be taken during the satellite development to ensure that we don’t become constrained by the mental models moulded from our experience thus far.

What is a mental model?

Everyone, based upon their experiences, goals, cultural background and other influences, forms a mental model.  Therefore, how we see the world shapes our view and the actions we take.  This has the potential to ‘blind’ the individual to certain aspects through lack of relevant experience or make them overly sensitive to other areas due to a negative experience.  It could also mean they assume that something that has worked well before will continue to work well in the future.

In order to prevent inadvertent biasing or constraining the way in which the Open Source Satellite problem is analysed, the ‘whole’ needs to be considered which means taking a holistic approach.  This involves looking at the system within the context it is to be used, the interactions between the various aspects of the system (internally and within its environment) and the impact of changes.

One simple example of the need to consider the whole is given by the parable of “The Blind Men and the Elephant”.  Several blind men encounter an elephant and each individually interacts with a separate part of the elephant.  Each, based upon the mental model that they have constructed of what they have observed (via touch) and their prior experience, form an opinion on what they think they have encountered.  For example, the one who interacted with the elephant’s tail may have thought that it was a piece of rope, another who interacted with the side of the body may have thought it was a wall and the one that interacted with the trunk may have thought it was a snake.  Having each of them then describe the elephant based upon their limited interaction meant that none of them had the same description nor an understanding of what they had really encountered.  In the parable, the blind men ultimately come to blows due to the suspicion that the others are being dishonest.  To help avoid this situation, an awareness that others will have different perspectives is needed and mechanisms implemented to facilitate the unification of these views.

What is the composition of the Open Source Satellite team?  And why is this important?

The core of the Open Source Satellite team is comprised of individuals with significant experience within the field of design, manufacture and operation of small satellites.  These have spanned a wide variety of customers and applications.

All of the mission and project experience that the team has acquired to date will contribute to our collective mental model about the satellite industry, customer needs, our approach to design work, the emphasis put on certain areas and our perception of risk.

Similar but different…

Despite our similar backgrounds, our differing individual experiences result in the use of different terminology and understanding of the environment within which the Open Source Satellite will sit.  Therefore, in order to achieve better alignment, our first undertaking has been the construction and iteration of a shared ontology.

The ontology is capturing the concepts which are specific to the domain within which the Open Source Satellite exists and the relationships between these concepts.  This is forming the basis of a shared language which is being used within the team, helping to ensure that the artefacts that are generated are consistent and can be understood by anyone with knowledge of the ontology.

Developing the ontology

An extract of our ongoing ontology definition work is shown in the figure below.  It has been captured using Systems Modelling Language (SysML) notation.

Another example of the building blocks of our shared ontology can be found in the figure contained within our earlier article “From stakeholder viewpoint to satellite platform design, using MBSE”.

The ontology is envisaged to be a live artefact.  At the outset we are unlikely to have uncovered all of the terms, concepts and relationships that exist, but it is already providing a common language for the team and the community, to communicate and understand each other.  It will provide a sanity check as to whether what we introduce into the Open Source Satellite programme fits within the concepts that are collectively understood, and if not, facilitate discussion as to why not: is it something that is already captured masquerading under a different name or is it something that has truly been missed?

So, we have a common language, what next?

The decisions that go into defining the ontology and what the Open Source Satellite programme consists of is a very powerful way of sharing the individual mental models to develop a collective mental model that is shared by the team.  This opens the door to starting the systems thinking around the needs of the different stakeholders and how this translates into the resultant Open Source Satellite.

The Open Source Satellite ontology will be loaded onto the repository in due course and we would welcome any comments and feedback.

Do you have any “gotchas” or experiences where a lack of common understanding and shared mental model has led to issues?  Or do you have any tools and techniques that have worked well to ensure that everyone is speaking the same language?  Let us know in the comments section below.

www.opensourcesatellite.org exists to create an environment that supports and enables entrepreneurial and innovative thinking, with the aim of taking the next step in small satellite capabilities.
Join our community, follow us and be part of the journey!