| Ticket # |
Date Initiated |
Status 9 Incomplete |
O-PAS™ Version |
Part |
Section |
PR/CR |
Disposition |
| |
|
|
|
|
|
|
|
|
| 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…$$ |
|
| 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).
|
|
| 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. |
|
| 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. |
|
| 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? |
|
| 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? |
|
| 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. |
|
| 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. |
|
| 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. |
|
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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. |
| 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 |
| 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 |
| 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… |
| 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 |
| 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. |
|
| 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 |
| 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 |
| 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. |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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. |
| 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. |
| 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 |
| 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. |
| 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
|
| 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. |
| 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 |
| 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 |
| 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 |
| 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 |
| 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. |
| 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]. |
| 230029 |
Jun 13, 2021 |
Complete |
2.1A Final |
7 |
Appendix |
Correcting error(s) in the appendix diagrams. |
Corrected |
| 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] |
| 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. |
| 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. |
| 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. |
