Contents

The SCM detailed here must primarily work within the confines of the Git (and GitHub) version control systems. It must, in addition, provide a navigable set of revision numbers, both for each module within the PAL and for each revision of the TIA Portal project that contains those modules.

The revision numbering mechanism must be clear, readable (by humans) and explain the current status of the software (i.e. under development, under test, in qualification or released for use).

Git and GitHub use commit numbers derived from the checksum of files being added to the repository. These appear at best to be seemingly random seven-digit^†1 hexadecimal numbers. They do not represent a meaningful number that is useful for team members trying to identify a revision path.

†1		These commit numbers are of course not random numbers. They are a checksum carried out of all the files in a commit, plus a header that contains other information (the commit numbers that immediately preceded this commit, plus some information about directory structures &c.).
		A checksum is basically a function applied to the binary value of every byte in a file that gives a reproducible figure that can be used to check to see if two files are the same or to identify data corruption within a file.
		The commit number used by Git is a checksum encoded by using the SHA-1 algorithm (Secure Hash Algorithm 1). This produces a 20-byte (40 digit) hexadecimal number that uniquely identifies a commit. The commit number shown is just the first seven digits of the full commit number. This is usually enough to uniquely identify a commit (even on very large projects).
		The first seven digits of a commit number gives 268 million unique values, the full 20-byte number has 1.5×1048 unique values (a similar number to the quantity of atoms that make up the Earth); these values also only apply within a repository (two different repositories can have the same commit number, they don’t interact with each other).
		The chance of a duplicate 20 byte commit number is vanishingly small, and is generally not a consideration, even on every large projects.

Git and GitHub do however, allow any commit point to have an associated tag, this is entirely at the discretion of the user and (other than the requirement of being unique) can be anything at all.

This allows each commit point to be tagged with a more meaningful (semantic) version number. Something that makes sense to humans.

This sematic version numbering scheme (used to tag each commit point) will provide a unique number that identifies the current revision of the software module and also provide status information about which of the phases of software development the software is currently in:

• Software development (system build)

• Under test

• Commissioning and qualification

• Released for use

The software version numbering scheme will be incremental in nature (the revision numbers will only go up), this provides a traceable approach to the software, it will always be possible to distinguish between earlier and later versions of the software, simply by examining the version numbers.

To complicate matters, the individual software modules do not exist within their own right, each software module is stored in TIA Portal project that expands as each new software module is developed. These TIA Portal projects exist on multiple development branches (see section 3) within the VCS (Git and GitHub) repositories, these TIA Projects must also form part of the Software Control Mechanism(SCM).

The testing of individual software modules (software module testing) and the testing of multiple modules (software integration testing) is carried out at specific intervals throughout the course of the Project, each such test must have its own TIA Portal “test” project as a record of the test (allowing the test to be repeated if required). Again, the SCM must provide a mechanism for recording and storing each test revision of the software.

There are seven components that are necessary and required by the SCM in terms of version control and management:

1. Version tracking of individual modules within a TIA Project or files within a website

2. Version tracking of the TIA Projects containing the individual modules

3. Filename allocation to the various TIA Projects

4. Workflow arrangements for the VCS, including branching and merging procedures

5. Local storage locations of TIA Projects and VCS repositories

6. Remote storage of the VCS repositories (GitHub)

7. Internal (PSP) backup mechanism for TIA Projects

Each of these components is addressed in the remainder of this document.