OPAF PRCR List

Problem Report / Change Request Process

Screen Shot 2021-07-14 at 8.32.23 AM.png

Problem Report / Change Request Log

	A	B	C	D	E	F	G	H
	Ticket #	Date Initiated	Status	O-PAS™ Version	Part	Section	PR/CR	Disposition
	275067	Jan 7, 2026	Incomplete	2.1	6.2	6.4.7	For O-PAS specification Part 6.2 - section 6.4.7 - Table 11: FBExecutionEngineType Definition has the following error IsAbstract TRUE Should have been IsAbstract FALSE In addition the first paragraph last sentence The FBExecutionEngineType defined in this document is an abstract type that can be sub-classed and defined for each control application type defined in subsequent parts of the O-PAS Standard (Part 6.5 - IEC 61499 and Part 6.6 - IEC 61131). Should be The FBExecutionEngineType defined in this document can be sub-classed and defined for each control application type defined in subsequent parts of the O-PAS Standard (Part 6.5 - IEC 61499 and Part 6.6 - IEC 61131). The text "is an abstract type that" should be removed
	275066	Jan 7, 2026	Incomplete	2.1	4	5.5.1	In O-PAS Part 4 - Section 5.5.1 - Table 10 OCF-001: OPC UA Client/Server Profile definition has one row that is in error CRQ-P4-0046 Sessionless Server Facet<http://opcfoundation.org/UA-Profile/Server/SessionLess> OPC 10000-7: Profiles M Has an error it row should be CRQ-P4-0046 Sessionless Server Facet<http://opcfoundation.org/UA-Profile/Server/SessionLess> OPC 10000-7: Profiles O The M shall be O
1	261698	Sep 6, 2024	Incomplete	2.1	6.2	Nodeset Files	When trying to follow the link in 6.2 to download the nodeset file, it leads to a broken page and it is not possible to download the document. Example: http://open-process-automation.projects.opengroup.org/twg/part-6-inform…
2	249720	May 24, 2023	Incomplete	2.1 Final	6.2	Appendix A.1	Problem: The information model schema released with the O-PAS Standard, Version 2.1 can be found here: http://open-process-automation.projects.opengroup.org/twg/part-6-inform…; The xml schema throws an error: "error on line 48 at column 91: Namespace prefix ua on ModelInfo is not defined" Action: Please advise how to resolve the Namespace prefix "ua". Link to screenshot (if applicable): https://www.cognitoforms.com/fa/ylGVbCpzMEKBHXWLOXCFnw?token=1iqqpDCD9K…$$
3	251867.1	Aug 14, 2023	Incomplete	V3 Draft	6.4	Table 7	(I'm looking at the V3 draft, so the figure and table numbers come from that) Figure 4 shows "ActualValue" as a Property of "Out". Table 7 shows "Out" has TypeDefinition 4:AnalogUnitRangeScaleType. That inherits from: AnalogUnitRangeType AnalogItemType DataItemType BaseDataVariableType BaseVariableType. None of those types has "ActualValue". The Part 6.4 writeup for the AI block does not have any references to Out.ActualValue. Unrelated to the above, but also in Figure 4, use of "HasComponent" and "HasProperty" also seems awry. Example, In.ActualValue seems like a Component, but it is marked as a Property. In.EURange and In.EngineeringUnits have neither Component nor Property markings and are probably HasProperty references. In the opposite direction, LowCutLimit is shown as Component and is probably a Property (similar to PA-DIM LowFlowCutOff). Management summary: I think ActualValue should be removed from "Out" in Figure 4. Some things in Figure 4 are using the "HasProperty" symbol (2 hash marks on line) and they should use the "HasComponent" symbol (1 hash).
4	251867.2	Aug 14, 2023	Incomplete	2.1 Final	6.4	Table 22	Table 22 shows PIDControlParameterType is a subtype of "FolderType". I'm no expert on OPC UA info models, but it seems TypeDefinitons are usually subtypes of "BaseObjectType" or "BaseVariableType", not "FolderType". in this case, I expected "BaseObjectType" (because there is no Value attribute). It seems unusual to add configuration Properties to a Folder.
5	251866.1	Aug 14, 2023	Incomplete	2.1 Final	6.2	Section 6.5.4	Just checking that AnalogUnitRangeScaleType of Part 6.2 Section 6.5.4 should not be OPASAnalogUnitRangeScaleType. It seems like many of the types introduced by O-PAS are prefixed with "OPAS", and I wondered if this one should be as well.
6	251866.2	Aug 15, 2023	Incomplete		6.2	Section 4.2.2	UA-Alias vs. UA-Tag? part 6.2, section 4.2.2, about UA-Alias Role Class, says: The primary purpose is to serve as the parent role for other Role Classes that reflect specific types of aliases; e.g., UA-TagVariable but the next section, 4.2.3 about UA-TagVariable says that inherits from UA-Tag, not UA-Alias. I don't see any references in 6.2 to UA-Alias and I don't see a definition in 6.2 for UA-Tag. (and Carl says the aml file is similar). Might UA-Alias and UA-Tag be mixed up?
7	251866.3	Aug 15, 2023	Incomplete		6.2	Section 6.7.1	OPC Tags vs TagVariables Part 6.2 Section 6.7.1 says If configured, O-PAS SignalType instances shall register the Tag variable to the Objects.Aliases.Tags (refer to OPC 10000-17 for more information on alias) [CRQ-P6.2-0017]. but I don't see anything called "Tags" in OPC 10000-17. Should this be Objects.Aliases.TagVariables?
8	251866.4	Aug 15, 2023	Incomplete		6.2	Section 6.7.1	In part 6.2, Section 6.7.1, it says: If configured, O-PAS SignalType instances shall register the Tag variable to the Objects.Aliases.Tags (refer to OPC 10000-17 for more information on alias) [CRQ-P6.2-0017]. "SignalType" is italicized. The full term "O-PAS SignalType" is not used or defined elsewhere in 6.2. That leads to the question of whether PA-DIM's "SignalType" is intended or the term "O-PAS Signal" is intended. 6.2 defines O-PAS Signal as OPC variables exchanged over OCF are termed O-PAS signals. O-PAS signals are in the same type hierarchy as PA-DIM signals, and anywhere an O-PAS signal is required, a PA-DIM signal may be used. but, the PA-DIM signals as shown in Figure 3, etc., are "VariableTypes" and PA-DIM's "SignalType" is an "ObjectType". Thus "SignalType" is not in the inheritance hierarchy of any of the O-PAS Signals. This seems like a problem when we get to the statement above from Section 6.7.1, where it says instances of SignalType shall register the Tag variable... 1. O-PAS does not have instances of SignalType. We have Variables, and SignatlType is an Object. 2. The PA-DIM "VariableTypes" such as AnalogSignalVariableType, do not contain a Variable called "Tag". The PA-DIM SignalType Object _does_ have a variable called "SignalTag", so perhaps that is what is intended to be registered as the Alias, but since O-PAS Signals are not a subtype of "SignalType", they do not have this "SignalTag" variable Component. Afaict, there is no Tag Name in an O-PAS Signal to Register as an Alias. It is possible, likely even, that I'm not understanding what to Register as an Alias for what, but if I am, then it is likely others will. Minimally, let's clear up whether "SignalType" means O-PAS Signal or PA-DIM SignalType, and whether "Tag" means "SignalTag" as defined within PA-DIM SignalType.
9	251866.5	Aug 15, 2023	Incomplete		6.2	Section 6.8.2	section 6.8.2 says CRQ-P6.2-0002 CRQ-P6.2-0002: O-PAS Signal Tag Alias Section 3.2 but I don't see anything about "Alias" in section 3.2 That CRQ is defined in section 3.1 The next row in the table of section 6.8.2 says CRQ-P6.2-0003 CRQ-P6.2-0002: O-PAS Signal Types Section 3.2 and it looks like the CRQ in this row should be -0003, that also is defined section 3.1. (and maybe part of my confusion on previous CR is that in this 3.1 section, CRQ-P6-6.2-003 says, Vendors shall use the SignalTypes defined in Table 2.... as if they derive from "SignalType" and that "SignalTypes" is a special word (because it is italicized). I don't find any hits in the OPC UA spec searching for "SignalTypes". Maybe it is not intended to be a special term, and should just be "signal types" and if so, maybe make it more specific, "signal variable types" or something like that.
10	251866.6	Aug 15, 2023	Incomplete		6.2	Table 40	Table 40: ObjectType Reference for OCFB_Type, OCFB_OutType and OCFB_InType are all off by one.
11	241027	May 16, 2022	Complete	2.1A Final	1	Clause 3.2	Currently reads: An ACP is a real-time high availability computing platform with scalable computing resources (memory, disk, CPU cores) providing the determinism, low latency, and reliability needed to handle applications or services that require more resources than are typically available on a DCN. Consider changing to: An ACP is a real-time, optionally, high availability computing platform with scalable computing resources (memory, disk, CPU cores) providing the determinism, low latency, and reliability needed to handle applications or services that require more resources than are typically available on a DCN.	New See outcome of 2nd Special Topic Adjudication as a part of Company Review of Part 1. Look at Glossary definition. David F. suggestion: An ACP is a computing platform providing the determinism, low latency, and reliability needed to handle applications or services that require more resources than are typically available on a DCN Moved to Company Review, Reference Tag ID # 477, on Jun 29 by A. Ali
12	240981	May 13, 2022	Complete	2.1A Final	6.1		There is a need for a directory of Alias Names that multiple IDEs can interact with when an OPAS system instance consisting of components from multiple suppliers is being built. This CR is probably best associated with Part 6.1.	New Alias will be defined in the AML configuration file. Defining this as an interface is not a part of 2.1 Moved to Company Review, Reference Tag ID # 3, on Jun 29 by A. Ali
13	241033	May 16, 2022	Complete	2.1A Final	6.2	UML Diagram	Consider changing the name O-PAS Execution Engine to O-PAS Engine. Considering changing the name O-PAS Function Block Execution Engine to O-PAS Function Block Engine.	New Company Review of Part 6.1 Look at Glossary definition. Moved to Company Review, Reference Tag ID # 4051, on Jun 29 by A. Ali
14	238558	Feb 4, 2022	Complete	2.1B Final	6.4		In order to ensure that all implementations of the 61131 look the same in all 61131 engineering tools and can be used interchangeably the ""interface"" of the FBs in 61131 must clearly be defined, i.e. the name of the FB types and the names and data types of all VAR_INPUT and VAR_OUTPUT pins on the block must be clearly defined. For reference, see OCFB definition in Part 6.6. or how PLCopen defines their Motion FBs (https://plcopen.org/node/90?file=139). Note that the B/E column for Basic/Extended version of the FB is not relevant for O-PAS.	In Progress (new). See above and on track for closure in next week. Moves to adjudication as a part of Company Review. Moved to Company Review, Reference Tag ID # 3, on Jun 29 by A. Ali
15	236011	Nov 16, 2021	Complete	2.1B Final	7	Appendix A	A.2 DCP Step 1 : The Enclosure Options, Environmental. · Rack Room, is the intention that Equipment Rooms do not have HVAC, hence the ambient is 55DegC down to -20DegC. · SJB, Confirm DCN will be installed in an SJB in a Hazardous Area and replaceable under power · At present most suppliers equipment is rated -40DegC to +70DegC. concern is that high operating temperatures eg +65DegC require MIL spec components increasing cost · Hazardous Area: ATEX is prescribed, are UL/IECEx/CCCEx (China) considered at a later stage A 4.6 Services Required * Has OPAF evaluated that pass thru of asset management data is more performant than by passing the controller.	New This will be evaluated 2.2 Moved to Company Review, Reference Tag ID # 312, on Jun 29 by A. Ali
16	233436	Aug 30, 2021	Complete	2.1A Final	1		The O-PAS specification does not include a strategy for use of AML, i.e., it does not clearly state the problem(s) solved by its use nor does it explain how AML solves those problems / represents solutions to those problems. I don’t know the section to which this should be applied, but I think It’s Part 1.	To be fixed in Version 2.1B. In Progress Moved to Company Review, Reference Tag ID # 312, on Jun 29 by A. Ali
17	230907	Jun 19, 2021	Complete	2.1A Final	6.4		There is a need in Part 6.5 (and probably Part 6.6) to reference the interface and behaviors required for Cascade Control that lead to “bumpless” control. However, Part 6.4 does not have that capability broken out as a Facet. I’m requesting that such a Facet be created so that other parts can reference it.	In progress. Will break into two facets. control and non-control. On track for completion within the next few weeks. Deferred to Version 2.1 Final. In Progress. See above and on track for closure in next week. 6.5 has a writeup that can be moved to 6.4. Waiting for input from Don. Moves to adjudication. Moved to Company Review, Reference Tag ID # 347, on Jun 29 by A. Ali
18	235932	Nov 21, 2021	Complete	2.1B Final	7		As indicated earlier, drift of 0.5 ms in 5 hours (equivalent to 0.1 ms / hour) would typically require 0.027 ppm accuracy crystal (even without accounting for temperature variances). Such extremely accurate/stable crystal/clock do exist but as specialized oscillators (such as OCXO – oven controlled crystal oscillator). These are very expensive per our understanding (hundreds of $). We had a though that one might be able to make some measurements and compensations based on the offsets while the MTS is connected, but I would be surprised if orders of magnitude increase in accuracy could be achieved. As a reference, existing products that use SNTP for time sync (in M580), use crystals that are specified at around 50 ppm (3 orders of magnitude larger than the O-PAS need). For TSN operation, the target seems to be around 100 ppm but this seems reasonable since MTS is expected to be online all the time (and time exchange is very frequent – many times per second). I think it’s worthwhile pointing this out to the working group. Perhaps we’re missing something and maybe there are already feasible solutions out there that we’re not aware of, in which case, it would be great for us to learn about.	New This is corrected in part 7 v2.1 Close.
19	235488	Oct 28, 2021	Complete	2.1A Final	4	7	Change Section 7, Networking Profiles into Networking Facets. Update NET-001 - NET-006 to NET-F-001 - NET-F-006. Verify/update the wording used in Part 7 (DCP-001 definition) refers to Table 15 O-PAS Network Facets instead of "Network Profiles." As there would be multiple Facets in Section 7 that should not be included by a Profile; the conformance requirements in 7.1.1 should tie directly to the facets listed in the table. (Will provide track changed version of Part 4 to Part Owners alongside this CR)	In progress. Part 4 section 7 is where the profiles are located. Make sure that change is applied to Part 7. Part 4 is already updated as described. Part 7 still needs to be changed. Nov 10, 2021 - Part 7 still needs to be changed. Closing this PR/CR and opening a separate one for the changes that should be made in Part 7. Complete
20	235487	Oct 28, 2021	Complete	2.1A Final	4		The OCF-001 Profile defines that every server shall implement being able to call the RegisterServer(2) services to register itself for discovery. However, that's a service sent to LDS but the rest of the spec only talks about GDS which commonly don't implement that Service. How exactly are OCF-001 OPC UA Servers supposed to register at a GDS? Where are LDS expected to be in an OPAS System? Clarification is needed on how the process of Registering an OCF-001 OPC UA Server at a GDS works.	In progress for V2.1A. Not expecting this to be V2.1A currently. Even if informative - add some language to say that we need to wait for the OPC Foundation to sort this item out for V2.1A. HowWhere do we document issues like this? Gitlab issues? Reported as complete on Nov 18
21	228215	Apr 5, 2021	Complete	2.1A Final	4	7.1.1	I would like to propose a change to the Part 4 requirement for Cat 6 cable as part of CRQ-P4-0097 to also support Cat 5e, see page 19 image below. This is requested to allow more existing offerings to become O-PAS certified in the short term.	Change was applied. Requirement expanded to support CAT 6 and 5e. https://gitlab.opengroup.org/open-process-automation/twg/part-4-connect…
22	230896	Jun 18, 2021	Complete	2.1A Final	4	7.1.1	In all NET Profiles change the cable requirements from: The allowed cable types in all configurations are: • Intra-building on the same power source: Copper – Cat 6 with RJ45 connectors to The allowed cable types in all configurations are: • Intra-building on the same power source: Copper – Cat 5e or Cat 6 with RJ45 connectors	Merged with ticket 228215
23	238256	Jan 27, 2022	Complete	2.1B Final	6.2	Fig 1	Related to accuracy of modified version of Figure 1, O-PAS Common Objects, of Part 6.2. Most of the changes were to additions (in red), but one change applies to the base diagram. The team decided that the arrow head from Function Block to O-PAS Function Block Group should be an aggregation relationship. Therefore, the arrow head should be empty. If agreed, please apply the change, otherwise this can be cleared in the normal 6.5 call.
24	235895	Nov 12, 2021	Complete	2.1B Final	6.2		The OCFB_INs need to include their subscription information among their diagnostic information. This includes: 1. Alias to the O-PAS Signal 2. UpdateInterval 3. Deadband Option 4. Deadband Value Similarly, OCFB_OUTs should present their Alias. Here’s some definition material: Pin, Use, Data Type, Description OCFB OPC UA BrowseName Mapping Alias. Input, STRING This is the OCF identifier for the O-PAS Signal to be accessed by the OCFB. TagVariableAlias, UpdateInterval, Input, LTIME The frequency with which the O-PAS Signal should be updated by the OPC UA Server if a subscription is in effect (O-PAS_POLLED_EVENT or O-PAS_AUTO_EVENT). <Need a Name> DBOption, Input, BOOL Indicates how DeadBand should be applied to the Value of the O-PAS signal. Set to TRUE if the DeadBand is to be an Aboslute DB. Set to FALSE if the DeadBand is to be in percent of scale. <Need a Name> DeadBand, Input, REAL The Absolute Deadband to be used for OPC UA updates of this variable. See DataChangeFilter in OPC UA Part 4. <Need a Name>	In Progress. Everything completed except glossary work per Vien. Doc uploaded to Gitlab. Vien is closing this item with input from Lars. New document updated. Marked as complete on Jan 12. Dead band is made optional currently there is a common class with dead band that both analogue and digital dervices from. Is this correct? Action: take this in the next 6.5 meeting
25	235832	Nov 10, 2021	Complete	2.1B Final	6.2		In Part 6.2, Section 4.2.5 (4.2.6 for most recent edit) Basic-SignalInterface Interface Class, the following text appears: According to this text, it seems to me that the direction for an OCFB_OUT would be “Out” and “In” for an OCFB_IN, but the following snippets (for sections 4.2.20 and 4.2.21) seem to indicate the opposite.For this DCN3 valve positioner, I’d expect the OCFB to have Direction “Out”, while the IO Channel output would have the Direction “In”. The Alias would have direction “InOut”. Why are the OCFB directions not reversed (e.g., Out for OCFB_OUTs)?	In Progress. V Nguyen Reviewing. Marked as complete on Jan 12
26	234246	Sep 23, 2021	Complete	2.1B Final	6.2	2	There are several terms in Part 6.2, e.g., Function Block Group, that do not appear in either a local glossary or the O-PAS master glossary and are used in multiple parts, e.g. Part 6.5 uses Function Block Group. Such terms should be included in Section 2 of Part 6.2 so that the Glossary editor can pick them up for inclusion.	In Progress. Everything completed except glossary work per Vien. Doc uploaded to Gitlab. No Change.
27	230895	Jun 18, 2021	Complete	2.1A Final	6.2		Please add Diagnostic Functional Group to FB definition. It will be used by OCFBs to record diagnostics.	Change was applied
28	230894	Jun 18, 2021	Complete	2.1A Final	6.2		Problem: Part 6.2 does not define configuration parameters for OCFBs. Both Part 6.5 and 6.6 need to specify configuration parameters. A suggested set is provided. OCFB_INs The following is the minimum set required to establish a subscription to an O-PAS Signal using the OCF. Name Data Type Purpose Alias, STRING String representation of an OPC UA Alias for the O-PAS Signal to be monitored by the OCFB_IN UpdateInterval, TIME Update period for the subscription DeadbandAbsolute, REAL The amount of change in the value that may be ignored by the OPC UA Server OCFB_OUTs Name, Data type, Purpose, Alias, STRING String representation of an OPC UA Alias for the O-PAS Signal to be monitored by the OCFB_IN	Change was applied
29	230893	Jun 18, 2021	Complete	2.1A Final	6.2		The OCFBs should make their error code (ErrorID) available through the OCF. This could be as an entry in the Diagnostics folder or as a standalone variable. I’m unsure of other diagnostics that should be included. Those copied may have ideas	Change was applied
30	230892	Jun 18, 2021	Complete	2.1A Final	6.2	6.4.12	The entities mentioned in the Table 22 (Clause 6.4.12) and Table 23 (Clause 6.4.13) should be consistently named. I’d suggest ReceivedVariable and OutgoingVariable since we are receiving/sending and entire O-PAS Signal and not just thevalue.	Change was applied
31	230972	Jun 22, 2021	Complete	2.1A Final	6.2	Figure 11	I may have found an error in the diagram for the PADIM structure. Between DataItemType and AnalogItemType there should be a BaseAnalogType. I brought it up in the Paper Exercise meeting and they said it was also wrong on the PADIM website.	Change was applied
32	231806	Jul 13, 2021	Complete	2.1A Final	6.2	6.4.6	Change Function Block model group items modeling rule from mandatory to optional	Change was applied
33	231806	Jul 13, 2021	Complete	2.1A Final	6.2		Add IVendorNamePlate interface to OPASBaseEngineType. This allows vendor identification of the executon engine. Allows for orchestration workflow.	Change was applied
34	234265	Sep 23, 2021	Complete	2.1A Final	6.2	Table 20	Please make the following two changes to Part 6.2 Table 20: * change ReadBackIn to UseOutForReadBackIn * delete SISLatchFaultState * Please add the 5 FBOptions to Part 6.2 Table 20 as indicated in the attached file.	The changes have been made and a copy uploaded to GitLab. Completed on Ticket # 234209 and 234265
35	233029	Aug 18, 2021	Complete	2.1B Final	6.2	6.4.6	This request is related to PRCR # 231806 requesting that the functional groups modeling rule for the base FunctionBlockType (defined in Part 6.2) to be changed from mandatory to optional. Due to this change, the ControlFunctionBlockType, which is a subtype FunctionBlockType and defined in Part 6.4, will need to override the modeling rule for these functional groups and make them ‘Mandatory’.	Related to PRCR #231806. Need to confirm that changes were applied. Done.
36	231808	Jul 13, 2021	Complete	2.1B Final	6.2	8	Add a Layer-F Application Library	Add LIB-001. In progress. AML review is ongoing. Dec 8 Changes made considered done. Check with Vien on integration and gitlab update.
37	233481	Aug 31, 2021	Complete	2.1A Final	6.3		Part 6.3 does not requiring that the alarm limits be recovered from the run-time and stored back in the AML. Since they can be altered, we need to ensure that the user has a tool to recover and document the changes.	Deferred to Version 3.0
38	233481	Aug 31, 2021	Complete	2.1A Final	6.3		In reviewing Part 6.3, it occurred to me that we are not requiring that the alarm limits be recovered from the run-time and stored back in the AML. Since they can be altered, we need to ensure that the user has a tool to recover and document the changes.	During Weekly 6.3 meeting we decided that no action was required (submitter was present). This is a tools requirement related to Upload/download.
39	233073	Aug 20, 2021	Complete	2.1B Final	6.4	Table 6	Suggest removing the line highlighted in yellow below from Table 6. Question regarding the row highlighted below in Table 6 Table 6: AnalogInputBlockType Additional References Source Path Reference Type, Is Forward, Target Path, Inputs, Organizes, True, In, ActualValue, Outputs, Organizes, True, Out, ActualValue ‘Out’ is of type AnalogUnitRangeScaleType which does not include ActualValue.	The AI Out does not need the ActualValue attribute and it’s an AnalogUnitScaleType. There’s no need to transmit an unconverted and a converted value downstream – only the converted value as Value. I will omit the row in Table 6 with Out.ActualValue. Was row in Table 6 omitted? Dec 15 assume still open and in progress Jan 5 In Progress with schematic changes as well Jan 19 No Change Feb 23: Complete
40	227913	Mar 26, 2021	Complete	2.1A Final	6.4	3.2.6.1	PID Equation in Section 3.2.6.1 on Page 44 of the PDF. The three terms inside the parentheses are shown as being multiplied together. This is incorrect. In reality these three terms should be summed, rather than multiplied.	The reviewer is correct. The equation in the document is wrong. The code in the reference implementation is correct, i.e. additions, not multiplications. I have corrected.
41	231004	Jun 22, 2021	Complete	2.1A Final	6.4		The Part 6.4 Profiles in V2.1 Prelim of the OPAS Standard don’t make much sense. They seem to be tool or execution engine profiles but they really aren’t either of those. They are FBs that are run by an execution engine or configured by a tool but they aren’t part of a tool or execution engine, so how can they be certified as part of either of them. The Part 6.4 Profiles should be reworked.	LIB-002 has been added to the document to address the issue
42	231980	Jul 20, 2021	Complete	2.1A Final	6.4	3.2.4.2.2	the type defined in section 3.2.4.2.2 should be LinearizationType (not Linearization). The LinearizationType is used in Table 5	Change applied
43	231808	Jul 13, 2021	Complete	2.1B Final	6.6	8	Add an IEC 61131-3 O-PAS Function Block Library	Add LIB-001. In progress. 6.2 draft is full already. Security applicability and the AML trickles through here. When LIB-001 is completed for 6.2 then this will be finished for V2.1. Deferred to V2.1B. Dec 8 In Progress. Dec 15 In Progress. Jan 5 complete
44	235488	Oct 28, 2021	Complete	2.1A Final	7		Change Section 7, Networking Profiles into Networking Facets. Update NET-001 - NET-006 to NET-F-001 - NET-F-006. Verify/update the wording used in Part 7 (DCP-001 definition) refers to Table 15 O-PAS Network Facets instead of "Network Profiles." As there would be multiple Facets in Section 7 that should not be included by a Profile; the conformance requirements in 7.1.1 should tie directly to the facets listed in the table. (Will provide track changed version of Part 4 to Part Owners alongside this CR)	Nov 10, 2021 - Part 7 still needs to be updated to reflect the changes made in Part 4 for this PR/CR. Marked as complete on Jan 12
45	230029	Jun 1, 2021	Complete	2.1A Final	7	5.3	Proposing removal of [CRQ-P7-006] and adjusting the related text. Original text: For this requirement to be met, the MTS should not drift relative to actual time; i.e., it needs a reference such as GPS to hold it steady.	Removed Conformance Requirement [CRQ-P7-006]. New Text: For this requirement to be met, the MTS should not drift relative to actual time during the loss of signal ; i.e., it needs a reference such as GPS to hold it steady.
46	230029	Jun 1, 2021	Complete	2.1A Final	7	5.6	Proposing addition of a security requirement to Part 7 V2.1	Added Section 5.6 (Secure Boot Support). New Text: An O-PAS conformant DCP shall support secure boot as defined by UEFI specification 2.3.1 or newer [CRQ-P7-010]. Added Conformance Requirement [CRQ-P7-010].
47	230029	Jun 13, 2021	Complete	2.1A Final	7	Appendix	Correcting error(s) in the appendix diagrams.	Corrected
48	232797	Aug 11, 2021	Complete	2.1A Final	7	5.2	Expanding the current CRQ to incorporate baseplate architectures as well. Proposed text is below. Note: This physical connection could be provided directly in the DCP or through a switch connected to an RJ45 connector or another means that provides connectivity via an RJ45 connector.	Change Applied: Network Connection An O-PAS conformant DCP shall support a connection to network with auto-negotiation from at least 100Mbps through an RJ45 connector; aka 8P8C jack (FCC standard). [CRQ-P7-004]
49	233166	Aug 23, 2021	Complete	2.1A Final	7	5.2	We have consensus in the last Part 7 meeting to make a modification to section 5.2, expanding the current CRQ to incorporate optical connector as well. Proposed text is below. An O-PAS conformant DCP shall support a connection to network with auto-negotiation from at least 100Mbps through an RJ45 connector; aka 8P8C jack (FCC standard) or through an LC single-mode UPC connector [CRQ-P7-004]. Note: This physical connection could be provided directly in the DCP or through a switch or another means that provides connectivity via a conformant connector. Related to PRCR # 232797	Changes were applied to the latest version of the document currently in review as of Nov 11, 2021.
50	235778	Nov 8, 2021	Complete	2.1B Final	6.5 --> 6.6 once change is complete		In reviewing Part 6.5 (unpublished), the following OCFB_IN parameters were identified as things that should be in the Diagnostic Data for the OCFBs. Both Part 6.5 and Part 6.6 need to report them. UpdateInterval, DBOption, DeadBand. Make ReadOnly	In Progress. Action: Alex and Lars to close. Can't have PRCR on something that is not yet published. Reassign to Part 6.6. Reassign to Pt 6.6. Dec 15 in progress Jan 19 No change, in progress Feb 23 - Complete! Changes applied to 6.2 to close.
51	238671	Feb 9, 2022	Complete	2.1A Final	All		ABB Automation GmbH legal entity has changed name to ABB AG. This should apply for all instances where the name appears across the different Parts of the Standard	Change request was logged with The Open Group technical editing team. Change to be applied before each part enters Company Review.