Standardisation

Why support standardisation? Simply put standards are a key part of the building block of modular systems. It would be difficult to plumb a house, or drive a car, if every plumber and manufacturer did things their own way. As it stands we have commonly accepted ways of doing things - standard fittings for pipes, standard layout of car controls and so forth. Standards don't simply appear, they take time to develop and to be adopted. In some cases this is "de facto", i.e. by industry and users simply adopting one way of doing things that becomes the accepted norm and by a raft of commercial and non-commercial licensing agreements a standard is set. Often "de facto" standards are set by formal and semi-formal standards bodies where players with a common interest sit down together and agree a set of specifications that identify how parts of the system work together (the interface specifications). What distinguishes standards from product specs is that a standard sets out what something has to achieve and not (generally) how to achieve it. Generally then standards are written to state exactly what is mandatory (using keywords such as shall (EU preference) or must (favoured in the USA)) and what is strongly recommended (using the keyword should).

Sometimes industry cannot, or is unwilling to, set a standard by itself and in these cases "de jure" standards are prepared, often by the same people and formal and semi-formal standards development organisations as "de facto" standards. De jure standards are those required to ensure safety or to respect some regulation and are generally legally binding, i.e. to enter the market you have to comply with these standards. Of course in some markets de facto standards have similar market entry force but are not legally enforceable. The standards market has changed in the past few decades, particularly in telecommunications, where less and less of the standards produced are de jure but rather increasingly are born in a de facto environment for common self-regulated deployment.

Even the simplest of standards can absorb years of effort, attending meetings, building consensus and of course writing, testing, validating to ensure the resultant standard is fit for purpose. 

Standards development has over time developed a tool-set of its own and there is a degree of expertise in using this tool-set and applying it successfully. In addition most organisations don't develop that expertise or retain it for long - the demands of everyday business are such that in most cases standards experts cannot be retained as only standards experts. However development of a standard is a long process and requires development of contributions alongside critical review of other contributor's contributions. In many cases there is a delicate job to do of pushing a commercial competitor's proposal as the long-term strategic goal is better suited by backing them than the short-term tactical goal of having your own ideas and input accepted.

Comments

Post a Comment

Popular posts

Balancing functionality, usability and security in design

Image
Introduction When designing new devices or applications there is a requirement nowadays to consider there functionality, usability and security. While there has been a push through secure-by-design guidelines for security to be built-in from the beginning there are still gaps in implementation and part of these gaps are design considerations of functionality and usability. Part of this that doing security well is hard work, but it should never block useful functionality for the user. Ideally, when security interferes with key software capabilities, the security must be tweaked. The answer should never be to abandon the functionality and certainly not to abandon the security. Though achieving this balance is admittedly not straightforward. This blog post will aim to look at this triad and how they can be balanced and not compromise each other. Defining the Triad in design A triangle can be used to help explain the relationship between the concepts of security, functionality and ea...
Read more

Personal Interest - Unbuilt fleets of the Royal Navy

Image
Introduction Throughout the 20th Century the Royal Navy designed and examined different types of fleets that were never realised either due to budget constraints, arms treaties or the changing nature of war. These are only a few examples of the different types of unbuilt fleets. Some of these had prototypes built and tasted for the Royal Navy which would serve as technological testbeds. Images and info from secret projects forum, shipbucket, popular mechanics/science and naval-matters. Washington Naval Treaty (WNT) The  Washington Naval Treaty  was a treaty signed during 1922 among the major nations that had won  World War I , which agreed to prevent an  arms race  by limiting naval construction. It was negotiated at the  Washington Naval Conference , held in  Washington, D.C. , from November 1921 to February 1922, and it was signed by the governments of the United Kingdom, the United States, France, Italy, and Japan. It limited the construction ...
Read more

Personal Interest - RAF Unbuilt Projects

Image
  Introduction This blog post looks at the different groups of cancelled RAF projects. It will focus on the 50s, 60s, 90s/00s and a brief look at hypersonic research projects. While these projects were often cut or cancelled for budget or austerity reasons, they were also pushed by the changing nature of warfare firstly from conventional style WW2 warfare to the predicated quick, short scale nuclear war which was expected from 1947 to 1989. Later from the 90s and into the 21st Century a change from state on state conflict to facing insurgencies, counter-terrorism and peacekeeping missions again led to a change in how wars are fought. Though the work and research done on these projects would rarely go to waste with it being used and applied in other projects and works even if sometimes it could take another ten or twenty years before anything operational came of that work. There won't be large amounts of text explaining or exploring the designs there are far better sources f...
Read more