Fix minor typos in project documentation.

Autocoders/Python/README.md

@@ -12,13 +12,13 @@ Takes a topology XML file as input and generates all the configuration files nec
 Takes a topology XML file as input and produces a JSON dictionary with naming convention "Deployment" + Dictionary.json. The JSON dictionary is generated within the directory where JSONDictionaryGen was run, but this can be overridden by inputting a new output directory in -p/--path.
 
 ### testgen.py
-Testgen generates a test component in the same way that codegen does. It takes a component XML file as input and generates Tester.cpp/hpp, TesterBase.cpp/hpp, GTestBase.cpp/hpp, and a TestMain.cpp. TestMain.cpp and Tester.cpp/hpp won't be overwritten if they already exists. Rather, one should use command line option -m/--maincpp to overwrite TestMain.cpp and -f/--force_tester to overwrite Tester.cpp and Tester.hpp. Testgen supports absolute paths to inputted files, so you are able to call testgen on any file and the test component will be generated in the directory that testgen was called from.
+Testgen generates a test component in the same way that codegen does. It takes a component XML file as input and generates Tester.cpp/hpp, TesterBase.cpp/hpp, GTestBase.cpp/hpp, and a TestMain.cpp. TestMain.cpp and Tester.cpp/hpp won't be overwritten if they already exist. Rather, one should use command line option -m/--maincpp to overwrite TestMain.cpp and -f/--force_tester to overwrite Tester.cpp and Tester.hpp. Testgen supports absolute paths to inputted files, so you are able to call testgen on any file and the test component will be generated in the directory that testgen was called from.
 
 ### gds_dictgen.py
 GDS Dictgen is a tool for generating GDS XML Dictionaries that are named *TopologyAppDictionary.xml. The tool takes topology XML as input, and the generated dictionary contains all enums, serializables, commands, events, channels, and parameters present within the topology. GDS Dictgen supports absolute paths to inputted files, so you are able to call GDS dictgen on any file and the dictionary will be generated in the directory that GDS dictgen was called from.
 
 ### pymod_dictgen.py
-Pymod Dictgen is a tool for generation python modules for the GDS. The tool takes topology XML as input, and it generates command, event, channel, and parameter python modules within their own respective directories. The output path can be changed with command line option -o/--dict_dir. Pymod dictgen supports absolute paths to inputted files, so you are able to call testgen on any file and the directories will be generated in the directory that pymod dictgen was called from.
+Pymod Dictgen is a tool for generating python modules for the GDS. The tool takes topology XML as input, and it generates command, event, channel, and parameter python modules within their own respective directories. The output path can be changed with command line option -o/--dict_dir. Pymod dictgen supports absolute paths to inputted files, so you are able to call testgen on any file and the directories will be generated in the directory that pymod dictgen was called from.
 
 ### implgen.py
 Implgen is a tool that takes in component XML and generates ComponentImpl.cpp/hpp files. It is formatted in a very similar way to testgen.py. It generates the Impl files within whatever directory it was ran, and it has its own pytest in Autocoders/Python/test/implgen. Implgen also allows for absolute paths.
@@ -135,7 +135,7 @@ Cmake file that is present in all parts of directory tree to be built by cmake.
 
 ### Requirements
 
-The Autocoder's requirements are covered by installing the F´ software package. This is is covered by the install document 
+The Autocoder's requirements are covered by installing the F´ software package. This is covered by the install document 
 found at: [INSTALL.md](../../INSTALL.md).
 
 ## Schematron

Drv/Ip/docs/sdd.md

@@ -38,7 +38,7 @@ In order to use a Drv::IpSocket it must first be configured with a call to the `
 Once configured, it can be opened using `Drv::IpSocket::open`. Opening the socket will verify arguments, allocate
 system resources and form a connection.  In server implementations (Drv::TcpServerSocket) the open call will block until
 a client connection has been made.  It is safe to assume that a successfully opened socket is ready to send or receive,
-however; those calls may detect and error and close the socket in response.
+however; those calls may detect an error and close the socket in response.
 
 `Drv::TcpServerSocket::send` will attempt to send data across the socket. It will retry to transmit data a configured
 number of times on correctable errors before finally succeeding once all data has been transmitted or failing should the
@@ -56,7 +56,7 @@ called, the Drv::IpSocket should be ready for another call to `Drv::IpSocket::op
 
 ### Example Usage of Drv::IpSocket
 
-This sections will show some example usages of the Drv::IpSocket. In this section it is assumed the initialization is
+This section will show some example usages of the Drv::IpSocket. In this section it is assumed the initialization is
 done using a concrete derived class as shown in subsequent sections.
 
 ```c++
@@ -90,7 +90,7 @@ Drv::IpSocket& socket = Drv::TcpClientSocket;
 The Drv::TcpServerSocket class represents an IPv4 TCP server. It inherently provides bidirectional communication with
 a remote tcp client server. The TCP server must be started up such that it may listen for incoming client requests.
 Since this class is intended to communicate with exactly one client, no listen queue is provided and subsequent connects
-from clients will be ignored until the primary client has be closed. Like the TCP client packet drops will result in an
+from clients will be ignored until the primary client has been closed. Like the TCP client packet drops will result in an
 error.
 
 **Note:** the `Drv::TcpServerSocket::open` call will block until a client connects to the server.
@@ -101,7 +101,7 @@ socket that will listen for incoming connections.  `Drv::TcpServerSocket::startu
 will only close the client connection and does not affect the server from listening for clients, however; it does free
 up the server to accept a new client.
 
-`Drv::TcpServerSocket::shutdown` will close the TCP server from receiving any new clients and effective releases all
+`Drv::TcpServerSocket::shutdown` will close the TCP server from receiving any new clients and effectively releases all
 resources allocated to the server. `Drv::TcpServerSocket::shutdown` implies `Drv::TcpServerSocket::close` and client
 connections will be stopped.
 
@@ -165,7 +165,7 @@ this read task will reconnect to sockets should a disconnect or error occur. Onc
 until a `Drv::SocketReadTask::stopSocketTask` has been called or an error occurred when started without reconnect set to
 `true`.  Once the socket stop call has been made, the user should call `Drv::SocketReadTask::joinSocketTask` in order to
 wait until the full task has finished.  `Drv::SocketReadTask::stopSocketTask` will call `Drv::IpSocket::close` on the
-provided Drv::IpSocket to ensure that the any blocking reads exit freeing the thread to completely stop. Normal usage of
+provided Drv::IpSocket to ensure that any blocking reads exit freeing the thread to completely stop. Normal usage of
 a Drv::SocketReadTask derived class is shown below.
 
 ```c++

Os/Pthreads/docs/sdd.md

@@ -59,7 +59,7 @@ The queue maintains the following state:
 
 2. <a name="count">*Count*</a>: The current number of messages in the queue (starts at 0).
 
-3. <a name="maxCount">*Maximum Count*</a>: The maximum number of messages ever seen in the queue since instantiation. This the a "high water mark" of the queue.
+3. <a name="maxCount">*Maximum Count*</a>: The maximum number of messages ever seen in the queue since instantiation. This is the "high water mark" of the queue.
 
 4. <a name="queue">*Queue*</a>: The queue data structure itself. The queue memory is allocated in a `U8*` buffer of size: ([Message Size](#msgSize) + `sizeof(NATIVE_UINT_TYPE)`) * [Depth](#depth)
 
@@ -213,4 +213,4 @@ Test complete.
 ---------------------
 ```
 
-The Pthreads queues are significantly faster than posix queues on a single core. The Pthreads queue is marginally slower in a multi-threaded environment, but its performance is still very similar to the Posix queue implementation. Based on these results the the Pthreads queue is performant enough for single core flight systems. It also looks to have reasonable performance when multi-threaded. If we wanted better multi-core performance, we could look into implementing a [lock-free concurrent max heap data structure](http://www.non-blocking.com/download/SunT03_PQueue_TR.pdf).
+The Pthreads queues are significantly faster than posix queues on a single core. The Pthreads queue is marginally slower in a multi-threaded environment, but its performance is still very similar to the Posix queue implementation. Based on these results the Pthreads queue is performant enough for single core flight systems. It also looks to have reasonable performance when multi-threaded. If we wanted better multi-core performance, we could look into implementing a [lock-free concurrent max heap data structure](http://www.non-blocking.com/download/SunT03_PQueue_TR.pdf).

Ref/PingReceiver/docs/sdd.md

@@ -3,7 +3,7 @@
 
 ## 1. Introduction
 
-The `Ref::PingReceiver` is a demonstration component that accepts pings from the Health Component [HTML](../../../Svc/Health/docs/sdd.html) [MD](../../../Svc/Health/docs/sdd.md) and has commands to disable ping responses for testing purposed.
+The `Ref::PingReceiver` is a demonstration component that accepts pings from the Health Component [HTML](../../../Svc/Health/docs/sdd.html) [MD](../../../Svc/Health/docs/sdd.md) and has commands to disable ping responses for testing purposes.
 
 ## 2. Requirements
 

Ref/docs/sdd.md

@@ -53,7 +53,7 @@ Each software module that has a Software Design Document written can be found he
 
 ## 2. Topology
 
-The topology of the reference example is the interconnection of all the components used in the reference deployment (a deployment is a set of components connected together and compiled into a binary). There are a large number of connections so it is not feasible to show them all in one diagram. The following sections have views of the topology that show the connections for a particular purpose. The topology diagrams will be broken down into the core set of Command and Data Handling (C&DH) connections that would be reused from project to project as well as the connections unique to the reference example. The diagrams were generating using MagicDraw, while the [XML](../Top/RefTopologyAppAi.xml) defining the topology connections was generated using the MagicDraw plug-in developed for ISF.
+The topology of the reference example is the interconnection of all the components used in the reference deployment (a deployment is a set of components connected together and compiled into a binary). There are a large number of connections so it is not feasible to show them all in one diagram. The following sections have views of the topology that show the connections for a particular purpose. The topology diagrams will be broken down into the core set of Command and Data Handling (C&DH) connections that would be reused from project to project as well as the connections unique to the reference example. The diagrams were generated using MagicDraw, while the [XML](../Top/RefTopologyAppAi.xml) defining the topology connections was generated using the MagicDraw plug-in developed for ISF.
 
 ### 2.1 Commanding
 

Svc/ActiveLogger/docs/sdd.md

@@ -56,7 +56,7 @@ event is seen.
 
 The `Svc::ActiveLogger` `LogRecv` input port handler filters events to lessen the load on the downstream components. The
 filters can be set by severity and ID. By default, the DIAGNOSTIC events are filtered out since the number of DIAGNOSTIC
-evens can be quite high.  All defaults can be globally configured in `config/ActiveLoggerImplCfg.hpp`. Filters are
+events can be quite high.  All defaults can be globally configured in `config/ActiveLoggerImplCfg.hpp`. Filters are
 modified at runtime by the `SET_EVENT_FILTER` command.
 
 The component also allows filtering events by event ID. There is a configuration parameter that sets the number of IDs

Svc/ActiveTextLogger/docs/sdd.md

@@ -12,7 +12,7 @@ The requirements for `Svc::ActiveTextLogger` are as follows:
 Requirement | Description | Verification Method
 ----------- | ----------- | -------------------
 ISF-ATL-001 | The `Svc::ActiveTextLogger` component shall print received log texts to standard output. | Unit Test; Inspection
-ISF-ATL-002 | The `Svc::ActiveTextLogger` component shall write received log texts to a optionally supplied file. | Unit Test
+ISF-ATL-002 | The `Svc::ActiveTextLogger` component shall write received log texts to an optionally supplied file. | Unit Test
 ISF-ATL-003 | The `Svc::ActiveTextLogger` component shall format the passed log text on the calling thread context, and perform all other processing on the component's thread. | Inspection
 ISF-ATL-004 | The `Svc::ActiveTextLogger` component shall stop writing to the optional file if it would exceed its max size. | Unit Test
 ISF-ATL-005 | The `Svc::ActiveTextLogger` component shall provide a public method to supply the filename to write to and max size. | Unit Test
@@ -39,13 +39,13 @@ Port Data Type | Name | Direction | Kind | Usage
 
 ### 3.2 Functional Description
 
-The `Svc::ActiveTextLogger` component provides an text logging function for the software that maintains consistent ordering by writing the logs from a thread.
+The `Svc::ActiveTextLogger` component provides a text logging function for the software that maintains consistent ordering by writing the logs from a thread.
 
 #### 3.2.1 File Writing
 
 Once a valid file and max size is supplied via a public function call, the `Svc::ActiveTextLogger` component writes to that file as well as standard output.  The `Svc::ActiveTextLogger` component will stop writing to the file if it would exceed the maximum size.
 
-If the file supplied already exists, the `Svc::ActiveTextLogger` component will attempt to create a new file up to ten times by appending a integer suffix to end of the file name.
+If the file supplied already exists, the `Svc::ActiveTextLogger` component will attempt to create a new file up to ten times by appending an integer suffix to end of the file name.
 
 ### 3.3 Scenarios
 

Svc/AssertFatalAdapter/docs/sdd.md

@@ -3,7 +3,7 @@
 
 ## 1. Introduction
 
-`Svc::AssertFatalAdapter` is an passive component that intercepts calls to FW_ASSERT and issues FATAL events for each.
+`Svc::AssertFatalAdapter` is a passive component that intercepts calls to FW_ASSERT and issues FATAL events for each.
 
 ## 2. Requirements
 

Svc/BufferManager/docs/sdd.md

@@ -83,7 +83,7 @@ When `BufferManager` receives a request for a buffer of size *s* on
 When `BufferManager` receives notification of a free buffer on
 [*bufferSendIn*](#bufferSendIn), it carries out the following steps:
 
-1. Check to see if it an empty buffer. If so, issue a WARNING_LO event and return.
+1. Check to see if it is an empty buffer. If so, issue a WARNING_LO event and return.
 2. Extract the manager ID and buffer ID from the context member of the `Fw::Buffer` instance.
 3. If they are valid, use the buffer ID to find the allocated buffer.
 4. Clear the "allocated" flag to make the buffer available again.

Svc/CmdDispatcher/docs/sdd.md

@@ -44,7 +44,7 @@ The `Svc::CmdDispatcher` component provides command dispatching. The architectur
 
 #### 3.2.1 Command Registration
 
-An autogenerated function on components create a public function `regCommands` that tells components to register the set of op codes that are implements by the component. The autogenerated port is connected to the `compCmdReg` input port on `Svc::CmdDispatcher` that corresponds to the number of the `compCmdSend` port used to dispatch commands. The port handler looks through the dispatch table for an unused entry and adds the opcode. It maps the opcode to the dispatch port number corresponding to the registration port number.
+An autogenerated function on components create a public function `regCommands` that tells components to register the set of op codes that are implemented by the component. The autogenerated port is connected to the `compCmdReg` input port on `Svc::CmdDispatcher` that corresponds to the number of the `compCmdSend` port used to dispatch commands. The port handler looks through the dispatch table for an unused entry and adds the opcode. It maps the opcode to the dispatch port number corresponding to the registration port number.
 
 #### 3.2.2 Command Dispatch
 

Svc/Health/docs/sdd.md

@@ -99,9 +99,9 @@ Off-nominal testing contains cases which deal with ping-related issues such as l
 
 ## 6.1 Unit Test Descriptions
 ### 6.1.1 Nominal Telemetry Test
-When the Health component's schedIn handler is called, each ping entry in the user provided table is check if it's enabled. If the entry is enabled and empty, a ping is sent out through its corresponding port. If the entry is awaiting a ping response, its counter is checked against a warning threshold and the counter is decremented. If the warning threshold is reached, an EVR and telemetry write are generated. If the fault threshold is reached, a fatal EVR is generated. 
+When the Health component's schedIn handler is called, each ping entry in the user provided table is checked if it's enabled. If the entry is enabled and empty, a ping is sent out through its corresponding port. If the entry is awaiting a ping response, its counter is checked against a warning threshold and the counter is decremented. If the warning threshold is reached, an EVR and telemetry write are generated. If the fault threshold is reached, a fatal EVR is generated. 
 
-This test invokes the schedIn handler for multiple iterations with a provided tables of three ping entries. To test nominal conditions, when a ping is received through the test port, a valid ping return is sent back to the component.  
+This test invokes the schedIn handler for multiple iterations with a provided table of three ping entries. To test nominal conditions, when a ping is received through the test port, a valid ping return is sent back to the component.  
 
 For this nominal condition, no EVRs or telemetry are expected.
 
@@ -138,7 +138,7 @@ This test verifies the requirement that the component shall stroke a watchdog po
 Requirement verified: `HTH-007`
 
 ### 6.1.8 Nominal Command Test
-This test verifies the functionally of all the provided health commands including the enable/disable monitoring of the ping entries as well ass updating timeouts. All commands are validated and verified with nominal inputs. 
+This test verifies the functionally of all the provided health commands including the enable/disable monitoring of the ping entries as well as updating timeouts. All commands are validated and verified with nominal inputs. 
 
 ### 6.1.9 Nominal Command and Telemetry Test
 This test is similar to `6.1.8`, but it includes a nominal running of the SchedIn handler while handling incoming commands. 

Svc/PrmDb/docs/sdd.md

@@ -3,7 +3,7 @@
 
 ## 1. Introduction
 
-The `Svc::PrmDb` Component is used to store parameter values used by other components. The values are stored in serialized form. During initialization, `Svc::PrmDb` loads a set of parameters from a file, and stores the values in a table based on the parameter ID. Components that need parameters request their values during initialization after they have been loaded. Components occasionally receive updates to parameter values via a command, and the new values will be send to `Svc::PrmDb`. A command will save the copy in memory back to the file.
+The `Svc::PrmDb` Component is used to store parameter values used by other components. The values are stored in serialized form. During initialization, `Svc::PrmDb` loads a set of parameters from a file, and stores the values in a table based on the parameter ID. Components that need parameters request their values during initialization after they have been loaded. Components occasionally receive updates to parameter values via a command, and the new values will be sent to `Svc::PrmDb`. A command will save the copy in memory back to the file.
 
 ## 2. Requirements