Abstract

The field of nanosatellites is constantly evolving and growing at a very fast speed. This creates a growing demand for more advanced and reliable EDAC systems that are capable of protecting all memory aspects of satellites. The Hamming code was identified as a suitable EDAC scheme for the prevention of single event effects on-board a nanosatellite in LEO. In this paper, three variations of Hamming codes are tested both in Matlab and VHDL. The most effective version was Hamming [16, 11, 4]2. This code guarantees single-error correction and double-error detection. All developed Hamming codes are suited for FPGA implementation, for which they are tested thoroughly using simulation software and optimized.

1. Introduction

Satellites have many applications, with earth observation (EO) being one of the primary applications. EO satellites use smart image sensors to monitor and capture data on the earth’s surface, and in some cases, infrared is used to look beneath. This information can be used to monitor urban development, vegetation growth, natural disasters, etc. With satellite imaging constantly evolving and improving, the captured information contains higher detail and improved resolution (smaller than 1 meter) making the data more useful. This is achieved, using a wide range of spectral band cameras [1]. With constant improvement, the captured data are becoming increasingly sensitive and valuable. This results in a growing need for security, privacy, and reliability on-board satellites [1, 2]. It has been proven that satellites whilst in orbit are susceptible to unauthorized intrusions, meaning a satellite can be hacked. Cryptographic protection can be implemented to provide protection against these intrusions. Usually satellite links are modelled with an AWGN channel [3, 4]. Encryption is the most popular and conventional method adopted for cryptographic protection against unauthorized intrusions, on earth and in space. Encryption on-board EO satellites have become the norm when data are transmitted between the satellite and the ground station [5]. However, the encryption algorithms typically implemented are proprietary or outdated algorithms like DES. This raises concerns as encryption algorithms protecting potentially highly sensitive information should meet the current and latest encryption standards [6].

The Hamming error correction and detection code were first introduced by Richard Hamming in 1950. The work initially conducted on Hamming codes allowed large-scale computing machines to perform a large number of operations without a single error in the end result [7]. Hamming code is a linear block error detection and correction scheme developed by Richard Hamming in 1950 [7]. This scheme adds additional parity bits (r) to the sent information (k). The codeword bits can be calculated according to . This means the amount of information data bits can be calculated by . Using a parity-check matrix and a calculated syndrome, the scheme can self-detect and self-correct any single-event effect (SEE) error that occurs during transmission. Once the location of the error is identified and located, the code inverts the bit, returning it to its original form. Hamming codes form the foundation of other more complex error correction schemes. The original scheme allows single-error correction single-error detection (SECSED), but with an addition of one parity bit, an extended Hamming version allows single-error correction and double-error detection (SECDED) [8]. Table 1 shows the original Hamming code’s classification and parameters:

The Hamming code initially started as a solution for the IBM machines that crashed when an error occurred. When the code was developed, it was considered a breakthrough but no one in 1950 could have predicted it being used to ensure data reliability on-board nanosatellites. Due to the capabilities and versatility of Hamming codes, new papers are constantly published.

1.1. Background

EDAC codes are classified mainly according to the approach the code takes when performing error detection and correction. Hamming codes fall under the following classifications: Error detection and correction codes => Forward error correction (FEC) => Block => Binary codes. This is shown graphically in Figure 1.

A Hamming block is basically a codeword containing both the information signal (k-bit long) and parity bits (r-bit long). The Hamming scheme can function using a systematic or nonsystematic codeword (Table 2).

1.2. EDAC Scheme Selection

The EDAC scheme selection is almost solely dependent on its application. The work in this paper focuses on EDAC on-board a nanosatellite. This implies that a solution is needed to detect and correct errors induced by radiation on-board a nanosatellite during its low earth orbit (LEO), specifically the ZA-Cube missions.

The ZA-Cube missions are a series of nanosatellite missions being developed by French South African Institute of Technology (FSATI) in collaboration with Cape Peninsula University of Technology (CPUT). The name of this initial nanosatellite is the ZA-cube 1 [9]. The successor to ZA-cube 1 will be ZA-Cube 2, which will orbit at around 550 Km [10].

Ideally, the effects of single-error upset (SEU) and multiple-error upset (MEU) should have been monitored in ZA-cube 1; unfortunately, this was not done and therefore, this information is unavailable. However, this data were gathered by the Alsat-1, which was the first Algerian microsatellite launched into LEO. This work was published [11]. This data is a good indication of what ZA-cube 2 will be exposed to, as the Alsat-1 is also sun synchronised orbit (SSO) and LEO (ZA-cube 2 orbit being roughly 100 Km closer to earth). This means the radiation dosages for ZA-cube 2 should be slightly lower than that experienced by the Alsat-1. However, the data from the Alsat-1 can be considered as a worst case scenario for ZA-cube 2. This data is shown Table 3 [11].

Using the data provided in Table 3, it becomes apparent that SEU is by far more likely error to occur as a result of radiation. SEU, on average, cause ±97 bit flips to occur during a single day (Figure 2). Obviously, the majority (about 80%) of these errors occur while the nanosatellite is traversing through the SAA which could range roughly between 5 and 10 minutes.

Using the information shown using Table 3 and Figure 2, Hamming code will be used as the EDAC scheme implemented to deal with SEU. Hamming code allows both error detection and correction of single-bit upsets and can be extended to detect double bit flips. Once a double bit flip is detected, the information can be erased and a request to resend the information can be raised. Should the nanosatellite be traveling through the South Atlantic Anomaly (SAA), it is possible to implement triple modular redundancy (TMR) that can deal with double-byte errors and severe errors.

Hamming code was selected mainly as it meets the EDAC requirements, implementation complexity is minimum and cost of additional hardware is kept minimal. For example, commercial off-the-shelf (COTS) devices can be used.

2. Overview of Hamming Code

In the sections to follow, a detailed overview of the Hamming code will be given. By touching on the parameters and foundation principles, the reader should have a solid understanding of the Hamming code.

Hamming code is an EDAC scheme that ensures no information transmitted/stored is corrupted or affected by single-bit errors. Hamming codes tend to follow the process illustrated in Figure 3. The input is errorless information of k-bits long which is sent to the encoder. The encoder then applies Hamming theorems, calculates the parity bits, and attaches them to the received information data, to form a codeword of n-bits. The processed information which contains additional parity bits is now ready for storage.

The type of storage is dependent on the application, which in this paper is RAM used by the on-board computer (OBC) of a nanosatellite. It is during storage that errors are most likely to occur. Errors usually occur when radiated particles penetrate the memory cells contained within the RAM. These errors are defined as bit flips in the memory. Hamming codes are capable of SECSED but can be extended to SECDED with an additional parity bit.

The decoder is responsible for checking and correcting any errors contained within the requested data. This is done by applying the Hamming theorem, which uses a parity-check matrix to calculate the syndrome. The decoder checks, locates, and corrects the errors contained in the codeword before extracting the new error-free information data.

2.1. General Algorithm

As mentioned previously, Hamming code uses parity bits to perform error detection and correction. The placement of these parity bits is dependent on whether or not the code is systematic or nonsystematic. In Table 4, a typical codeword layout is shown. Please note that this table only includes bit positions 1 to 16 but can continue indefinitely. From Table 4, the following observations can be made:(i)Bit position (codeword) is dependent on the amount of data bits protected(ii)Parity bit positions are placed according to, 2 to the power of parity bit:(a)20 = 1, 21 = 2, 22 = 4, 23 = 8 and 24 = 16.(iii)Parity bit’s relationship to bit position and data bits (also shown using Figure 4)(b)Parity bit 1 (P1) represents bit position: 1 (P1), 3, 5, 7, etc. (all the odd numbers)(c)Parity bit 2 (P2) represents bit position: 2 (P2), 3, 6, 7, 10, 11, etc. (sets of 2)(d)Parity bit 4 (P4) represents bit position: 4 (P4), 5, 6, 7, 12, 13, etc. (sets of 4)(e)Parity bit 8 (P8) represents bit position: 8 (P8), 9, 10, 11, 12, 13, etc. (sets of 8)(f)Parity bit 16 (P16) represents bit position: 16 (P16), 17, 18, 19, etc. (sets of 16)(iv)The position in between the parity bits are filled with data bits.(v)The layout makes each column have a unique parity bit combination, for each bit position.(vi)This unique parity bit combination is known as the syndrome value.

2.2. Construction of Generator Matrix (G)

Generator matrix (G) is used when encoding the information data to form the codeword. G forms one of the foundations on which the Hamming code is based. Due to the relationship between the generator matrix and parity-check matrix the Hamming code is capable of SECSED.

is defined as the combination of an identity matrix () of size and a submatrix () of size [12]:

2.3. Construction of Parity-Check Matrix (H)

Parity-check matrix (H) is used when decoding and correcting the codeword, in order to extract an error-free message. H forms one of the foundations, on which the Hamming code is based. Due to the relationship between the parity-check matrix and generator matrix, the Hamming code is capable of SECSEC.

is defined as the combination of a negative transposed submatrix (P) of size and an identity matrix (I) of size [12]:

2.4. The Relationship between G and H

The relationship between G and H is shown as

As a final note on G and H, it is possible to manipulate this matrix from systematic to an equivalent nonsystematic matrix by using elementary matrix operations, which are the following:(i)Interchange two rows (or columns)(ii)Multiply each element in a row (or column) by a nonzero number(iii)Multiply a row (or column) by a nonzero number and add the result to another row (or column)

2.5. Hamming Encoder

The Hamming encoder is responsible for generating the codeword (n-bits long) from the message denoted by (M) and generator matrix (G). Once generated the codeword contains both the message and parity bits. The codeword is calculated using the formula

The mathematical expression in (4) is essentially made up of AND and XOR gates. The gate/graphical expression is illustrated in (Figure 5).

2.6. Hamming Decoder

The Hamming decoder is responsible for generating the syndrome (r-bits long) from the codeword (n-bits long) denoted by C and parity-check matrix (H). Once generated, the syndrome contains the error pattern that allows the error to be located and corrected. The syndrome is calculated using the formula

The mathematical expression in (5) is essentially made up of AND and XOR gates. The gate/graphical expression is illustrated in Figure 6.

2.7. Extended Hamming Code

The extended Hamming code makes use of an additional parity bit. This extra bit is the sum of all the codeword bits (Figure 7), which increases the Hamming code capabilities to SECDED. The extended Hamming code can be done in both systematic and nonsystematic forms. Table 5 shows this in a graphical manner.

P16, in this case, is the added parity bit that allows double error detection. By monitoring this bit and checking whether the bit is odd or even allows the double bit error to be detected, which is shown in Table 5 by bold.

3. Hamming [16, 11, 4]2

Hamming [16, 11, 4]2 is an extended version of Hamming code. With an additional parity bit, the code is capable of double error detection (DED). This code was implemented in a nonsystematic manner, which simplifies the detection of double errors. The construction of the generated codeword is shown in Table 6. Using general formulas, some performance aspect of the Hamming [16, 11, 4]2 can be calculated (Table 7). This clearly proves that Hamming [16, 11, 4]2 has a better code rate and bit overhead than Hamming [8, 4, 4]2, with capabilities of SECSED.

In order to implement the Hamming [16, 11, 4]2, a generator matrix (G) and parity-check matrix (H) are needed for the encoding, decoding, and the calculation of the syndrome (S). The following calculations were done in order to implement the code:

Submatrix (P) of dimensions is shown as

Identity matrix (I) of size (7) is used when calculating G:

From (1), the generator matrix is calculated:

Following Hamming rules, G should be of size . Therefore, an additional column is needed to satisfy this condition for Hamming [16, 11, 4]2. An 8th parity column is added to G. This is done by adding an odd or even parity bit to each row:

By considering the nonsystematic Hamming bit layout in Table 4, G calculated in (9) can be rearranged to form a nonsystematic matrix G:

Identity matrix (I) of size is used to calculate H. From (2), the parity-check matrix can be calculated. With the additional parity bit, the negative submatrix is not used, as the result is the same. H is calculated in (11).

Hamming rules state H should be of size . Therefore, an additional column and row are needed to satisfy this condition for Hamming [16, 11, 4]2. Due to the fourth parity bit only being used for detection, the entire row can be filled with ones. With a fourth row added, an 8th parity column is added to H. This is done by adding an odd/even parity bit to each row.

By considering the nonsystematic Hamming bit layout in Table 4, H calculated above can be rearranged to form a nonsystematic matrix H:

Once G and H have been derived, it is possible to encode and decode the information data in a manner that is capable of SECDED. The data is encoded using (4). This was implemented in Matlab using mod-2 additions which are essentially exclusive-OR functions. The same equation was used to encode the information data in VHDL, however, exclusive-OR gates where used to perform the operation.

Hamming [16, 11, 4]2 makes use of syndrome decoding to locate and correct any errors that occurred in the codeword during transmission or storage. The syndrome is calculated according to (5). A for-loop or case statement can then be used to locate the bit which is flipped within the codeword. Once located, the bit is simply inverted, returning it back to its original and correct state. With the codeword now error-free, the information bits are separated and extracted, returning an error-free 11-bit message to the receiver.

4. Implementation

Hamming code was implemented in both Matlab and VHDL. The approach taken to achieve the desired results is explained with the help of detailed flow charts.

4.1. Matlab

For each variation of the Hamming codes, a proof of concept model was designed in Matlab. The approach is outlined in Figure 8.

4.2. VHDL

Once proof of concept was established using Matlab, Quartus was used to implement the working VHDL model. The Hamming code was programmed using VHDL as it allows the behaviour of the required system to be modelled and simulated. This is a major advantage when optimization is required. A working model of Hamming [8, 4, 4]2 and Hamming [16, 11, 4]2 was programmed in VHLD using the approached detailed in Figure 9.

5. VHDL Optimization of Hamming [16, 11, 4]2

In this section, the optimization of Hamming [16, 11, 4]2 is done. The aim of optimization is to reduce resource usages, reduce time delays, improve efficiency, etc.

5.1. Code Optimization

There are many ways of optimizing VHDL code. Some of the main topics when it comes to optimization are [13](i)Efficient adder implementation(ii)State machines(iii)Signal selection(iv)Storage structure(v)Placement and Routing

In this paper, the Quartus Prime package is used to code, analyse, compile, and optimize the Hamming code.

5.2. Register Transfer Level (RTL) Viewer of Hamming [16, 11, 4]2

Using the RTL viewer provided under tools in Quartus Prime, an overview of the I/O and VHDL code layout can be seen in Figure 10. The overview displays the input and outputs, as well as the components defined in hamming_11_16_main.vhd.

Using the RTL viewer tool, it is possible to step into both the encoder and decoder. The RTL viewer optimizes the netlist in order to maximize readability. This allows a unique insight into each VHDL code. The RTL view of the encoder and decoder is shown in Figures 11 and 12.

5.3. Optimization of Hamming [16, 11, 4]2

The following steps are taken to optimize the code:(i)Remove unnecessary and redundant code(ii)Reduce constants and variables where possible(iii)Minimize the use of if statements and loops(iv)Convert code to structural level or gate level

The Hamming [16, 11, 4]2 was reduced to structure or gate level, which resulted that all redundant codes, IF statements, loops, constants, and variables were either removed or reduced. By reducing the code to gate level, the following changes occurred:(i)Encoder contains no constants or variables(ii)Encoder went from performing 320 logic (AND and XOR) bit operations to only 30 XOR operations(iii)Decoder contains no constants(iv)Decoder contains a reduced amount of variables(v)Decoder went from 2 IF statements to none and from 1 case statement to none

The results of reducing Hamming [16, 11, 4]2 to gate level is shown for the decoder using Figure 13.

6. Testing and Simulations

Hamming codes have many communication and memory applications. They are extremely popular for their effectiveness when it comes to correction of single-bit flips and the detection of double-bit flips.

Hamming [16, 11, 4]2 allows SECDED, while providing a better code rate and bit overhead than standard Hamming codes. Hamming [16, 11, 4]2 generates a codeword of double-byte size, which is convenient as most memory blocks work on a byte standard. The code was implemented in VHDL on both a behaviour/dataflow and gate level (optimized) during implementation. Hamming [16, 11, 4]2 code was optimized from a resource reduction and timing approach, after which it was tested thoroughly using software techniques.

6.1. Top-Level Requirements

The top-level design in Figure 14 shows a proposed EDAC system. The i386 microcontroller communicates using 11 bits of data over the D-Bus. The data bits together with the 5 bits parity allow a double-byte codeword to be stored in the RAM. This layout ensures that SEUs are detected and corrected during memory read and write cycles.

6.2. Software Tests and Reports

Using software, the developed Hamming code is tested and analysed. This is done on three levels, namely, functionality (ModelSim), resource usage (compilation report), and timing analysis (TimeQuest). An overview of the tested VHDL code is shown in Figure 15. Figure 15 shows the inputs and outputs (I/O), I/O registers, clocking circuit, and the components that make up the Hamming [16, 11, 4]2 code.

6.3. Functionality

Hamming [16, 11, 4]2 is capable of single-error correction and double-error detection. With the help of ModelSim, this is clearly shown in Figure 16. I/O registers are triggered using the rising edge of clk and can be cleared using clr. This will allow synchronisation and enables the OBC to do a full EDAC reset if necessary. Datain (input), dataout (output), and data_to_memory (stored codeword) display the data in the system, while NE (no error), DED (double error detection), and SEC (signal error correction) serve as indication flags. In Figure 16, the functionality of Hamming [16, 11, 4]2 is proven. In Figure 16, the following should be noted:(i)All registers are cleared using the clear signal “clr” (this is shown using )(ii)Single-bit errors are introduced in memory using a bit flip in data_to_memory (bits 0 to 15) and flagged by SEC (this is shown using )(iii)Double-bit errors are introduced in memory using bit flips in data_to_memory (bits 0 to 15) and flagged by DED (this is shown using )(iv)Note: thanks to Hamming [16, 11, 4], dataout is unaffected by single-bit errors and only gets cleared upon the detection of double-bit errors.

In this paper, EDAC schemes are extensively discussed. ZA-cube 2 nanosatellite was used as a case study when conducting research on space radiation, error correction codes, and Hamming code. All findings, results, and recommendations are concluded in the sections to follow.

6.4. Findings

Space radiation has caused numerous mission failures. Through research, it became apparent that failures caused by SEU and MEU are extremely common and SEEs are more frequent while the nanosatellite is in the SAA. It was found that there are a number of EDAC schemes and techniques currently used, most commonly Hamming, RS codes, and TMR. The EDAC schemes are usually implemented using an FPGA. From the literature survey, it is clear that there is a need for research in the area of EDACs. By conducting an in-depth literature review, it was established that Hamming code was capable of performing the functionality desired.

In order to understand space radiation, a study was conducted using the orbital parameters of nanosatellite ZA-Cube 2. This radiation study was conducted using OMERE and TRIM software which allows the simulation of earth radiation belts (ERBs), galactic cosmic radiation (GCR), solar particle events (SPE), and shielding. In the case of ERBs, protons of a maximum integral flux of 1.65 × e3°cm−2·s−1 flux at energy ±100 KeV were trapped, which decays to a minimum integral flux of 1.55 cm−2 s−1 flux at energy ±300 MeV. It was found that the common nanosatellite casing of 2 mm Al is only effective as a shield against protons below 20 MeV and heavy ions below 30 MeV. In order to ensure that SEE does not occur, additional mitigation techniques are needed to protect sensitive/vulnerable devices. These techniques could be triple modular redundancy (TMR), software EDAC schemes, and others.

There are two types of ECC, namely, error detection codes and error correction codes. For protection against radiation, nanosatellites use error correction codes like Hamming, Hadamard, Repetition, Four Dimensional Parity, Golay, BCH, and Reed Solomon codes. Using detection capabilities, correction capabilities, code rate, and bit overhead, each EDAC scheme is evaluated. The evaluation of Hamming codes is shown in Table 8. Nanosatellites in SSO LEO of around 550 km experience on average ±97 SEU bit flips per day, with an average of 98.6% of all errors being SEU. Around 80% of all errors occur within the SAA region.

Hamming codes are classified as error detection and correction codes that are forward error correction block binary codes. These codes are based on the use of parity bits which allows EDAC using a generator matrix and a parity-check matrix. Normal Hamming codes make use of a syndrome decoder which ultimately allows the error to be located. Once located, the error is corrected to its original state. Three variations of Hamming was designed and tested during the completion of this paper. A short summary of these codes is shown in Table 9.

Hamming [16, 11, 4]2 was then converted to gate level and optimized from a resource approach and timing approach. The results of the optimized code are shown in Table 10. With the Hamming code design being complete, hardware tests were considered. The international JEDEC standards are recommended when conducting a proton (JESD234) and heavy ion test (JESD57A). These standards ensure reliable and accurate test results. iTemba lab in Cape Town houses an accelerator capable of proton (up to 200 MeV) and heavy ion testing. In order to conduct SEE tests at a facility like iTemba lab, detailed and extensive planning is necessary. This planning and actual testing are done by both the ion beam operators and satellite engineers. This ensures cost and time is kept to a minimal.

7. Conclusion

In this paper, a detailed look at different EDAC schemes, together with a code comparison study was conducted. This study provides the reader with a good understanding of all common EDAC schemes, which is extremely useful should different EDAC capabilities be needed.

Hamming code was extensively studied and implemented using different approaches, languages, and software. The final version of the Hamming code was Hamming [16, 11, 4]2. This code allows SECDED. Using only 12 adaptive logic modules (ALMs), the code is extremely small, meaning the selected FPGA will consume a minimal amount of power. By optimizing the resource usage, the average fan-out can be reduced from 1.81 to 1.59 and runs on a period of 1.8 ns with no violation and an arrival time of 5.987 ns. When optimized from a timing perspective, the code can be optimized to runs off a clock period of 1.8, with no violations and an arrival time of 5.394 ns.

Due to Hamming [16, 11, 4]2 resource usage of the original code already being so small, the timing optimization approach is recommended it is 0.593 ns faster. This implies that a Hamming code was developed capable of protecting 11 bits of information against SEU and capable of DED. The code is capable of reading and writing to memory within 5.394 ns using only 12 ALMs and 24 registers.

The data from Alsat-1 is considered as a worst case scenario. This means Hamming [16, 11, 4]2 is theoretically capable of preventing all single-bit errors (SBE) or ±98.6% of all SEUs experienced onboard ZA-cube 2. Hamming [16, 11, 4]2 detection capability also allows the prevention of some multiple-bit errors (MBE). Should the nanosatellite be traveling through the South Atlantic Anomaly (SAA), it is possible to implement triple modular redundancy (or a similar EDAC scheme) together with Hamming [16, 11, 4]2. This will equip the nanosatellite to deal with double-byte errors and severe errors.

The field of nanosatellites is constantly evolving and growing at an astonishing pace! This is due to the fact that it provides a platform from which the boundaries of space and technology are constantly being pushed. As technology advances memory chip cell architecture is becoming more and denser, especially with the development of nanotechnology. This creates a growing demand for a more advanced and reliable EDAC system that is capable of protecting all memory aspects of satellites. The code developed in this paper guarantees SECDED at fast speeds.

In this paper, EDAC schemes with a focus on Hamming codes are extensively discussed and studied. The ZA-cube 2 nanosatellite was used as a case study when conducting research on error correction codes, Hamming codes, and the optimizing of Hamming codes.

Data Availability

The data wherever required is referenced in the paper.

Conflicts of Interest

The authors declare that they have no conflicts of interest.