Skip to main content

OPAF PRCR List

Problem Report / Change Request Process

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

 

 

Problem Report / Change Request Log

PRCR List : PR/CR
  A B C D E F G H
 
Ticket # Date Initiated Status 10 Incomplete O-PAS™ Version Part Section PR/CR Disposition
                 
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.