USB Type-C Connector System Software Interface Specification Describes the specifications and capabilities of the USB Type-C Connector System software Interface (UCSI), and explains the registers and data structures, for hardware component designers, system builders, and device driver developers. Methodologies Working Group & Tools 1 System Interfaces – Definition and Design System Interfaces - Definition and Design Best Practices. 3.1.19 Interface specification. ISO/IEC. Content of systems and software life cycle process information products (Documentation) a) 10.27 Interface description.

In the Wikipedia link for SRS, in the 'Product Perspective' section, there is a mention of the term 'System Interfaces'. I am not clear as to what exactly that means. I have looked at a few other SRS samples available online but am not able to piece together an unambiguous definition from the examples. Could someone elaborate on what 'System Interfaces' refer to?

closed as too broad by TylerH, Kara, Claies, rene, Display Name is missingJan 30 '17 at 21:40

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers

The IEEE 830-1998 standard defines 'Hardware Interfaces' as

'the logical characteristics of each interface between the software product and the hardware components of the system'

Similarly, it defines 'User Interfaces' as

'the logical characteristics of each interface between the software product and its users'.

So, a little reasoning tells us that the 'System Interface' should have been defined as

'the logical characteristics of each interface between the software product and the bigger system'.

Software Interface Specification Template

That means, 'system interfaces' are not the bigger system's interfaces with the outside world, but the internal interfaces between the software and everything else within the bigger system, which includes user interfaces, hardware interfaces and software interfaces.

Ironically, the 830-1998 is written in a so inconsistent fashion that the recommended section hierarchy is:

where 2.1.1 should really be the parent section of 2.1.2 - 2.1.4.

So they gave some vague definitions of the 'system interfaces' section:

This should list each system interface and identify the functionality of the software to accomplish the system requirement and the interface description to match the system.

Whoever wrote this, please try get a B from the 12th grade English composition class!

Anyway, as a non-native speaker, my understanding of IEEE's version of the 'System Interface' is that:

1. Software may be an independent product made for general use (e.g. commercial software, video games, etc.), or it may be a part of a bigger system which contains both software and hardware. For example, a car is a system and the embedded computer software is only a part of the system. Another example is the software in a hospital CT scanner is also a part of the system (the machine).

2. Assuming the system requirement is defined before the software requirement (i.e. top-down approach), think about

a) what functionality your software must have in order to meet the system requirement? (can't forget the bigger picture)

For example, if a automatic driving car system requirement is that 'the car shall detect sudden slow downs of the vehicles in front of the car within 0.1 seconds', then you may need to write a non-functional requirement for your software system such as 'after the software receives the 'sudden slow down' signal from the front sensor, it shall process the signal and make decisions. If it is a confirmed real scenario (not a false alarm) then the software shall send 'hit break' signal to the break system. The decision making and signal sending process shall take no longer than 0.05 seconds.

b) what are the interfaces between your software and everything else within the bigger system?

E.g. your car computer software shall have the following interface with the front sensor:

Such interfaces shall be clearly defined.

If you software is not part of a bigger system, or if it is designed to be a generic software to be run in general systems (e.g. MS Windows applications), then there is little need for specifying the 'System Interfaces' section.

System interfaces include the following: 1. User Interfaces e.g. screen format,keys 2. Hardware interfaces e.g. configuration characteristics, devices supported 3. Software interfaces e.g. an OS 4. Communication Interface - LAN

Also, you may want to include a high level view of your system in relation to all these interfaces.

Let me know if you require more details.

System interfaces in the context will mean all interfaces your system will need to perform its purpose.

Probably if your server consumes a web service response / a Queue message or a database poll, they can be counted as 3 interfaces to your system. The implementation of these interfaces will be a SOAP impl, a ACTIVEMQ broker and a database.

Not the answer you're looking for? Browse other questions tagged srs or ask your own question.

Summary

• Microsoft-provided in-box UCSI driver for a USB Type-C system with an embedded controller.

Last Updated

• October 2018

Windows version

• Windows 10 for desktop editions (Home, Pro, Enterprise, and Education)
• Windows 10 Mobile

Official specifications

Microsoft provides a USB Type-C Connector System Software Interface (UCSI) Specification-compliant driver for ACPI transport. If your design includes an embedded controller with ACPI transport, implement UCSI in your system's BIOS/EC and load the in-box UCSI driver (UcmUcsiCx.sys and UcmUcsiAcpiClient.sys).

If your UCSI-compliant hardware uses a transport other than ACPI, you need to write a UCSI client driver.

Drivers for supporting USB Type-C components for systems with embedded controllers

Here is an example of a system with an embedded controller.

In the preceding example, USB role switching is handled in the firmware of the system and USB Role Switch driver stack is not loaded. In another system, the driver stack may not get loaded because dual role is not supported.

In the preceding image,

• USB device-side drivers

  The USB device-side drivers service the function/device/peripheral. The USB function controller class extension supports MTP (Media Transfer Protocol) and charging using BC 1.2 chargers. Microsoft provides in-box client drivers for Synopsys USB 3.0 and ChipIdea USB 2.0 controllers. You can write a custom client driver for your function controller by using USB function controller client driver programming interfaces. For more information, see Developing Windows drivers for USB function controllers.

  The SoC vendor might provide you with the USB function lower filter driver for charger detection. You can implement your own filter driver if you are using the in-box Synopsys USB 3.0 or ChipIdea USB 2.0 client driver.

• USB host-side drivers

  The USB host-side drivers are a set of drivers that work with EHCI or XHCI compliant USB host controllers. The drivers are loaded if the role-switch driver enumerates the host role. If your host controller is not specification-compliant, then you can write a custom driver by using USB host controller extension (UCX) programming interface. For information, see Developing Windows drivers for USB host controllers.

  Note Not all USB devices classes are supported on Windows 10 Mobile.

• USB connector manager

  Microsoft provides a UCSI in-box driver with Windows (UcmUcsiCx.sys) that implements the features defined by the UCSI specification available here. The specification describes the capabilities of UCSI and explains the registers and data structures, for hardware component designers, system builders, and device driver developers.

  This driver is intended for systems with embedded controllers. This driver is a client to the Microsoft-provided USB connector manager class extension driver (Ucmcx.sys). The driver handles tasks such as initiating a request to the firmware to change the data or power roles and getting information needed to provide troubleshooting messages to the user.

Hardware Software Interface Specification Iso 26262

UCSI commands required by Windows

See the UCSI specification for commands that are 'Required' in all UCSI implementations.

In addition to the commands marked as 'Required', Windows requires these commands:

• GET_ALTERNATE_MODES
• GET_CAM_SUPPORTED
• GET_PDOS
• SET_NOTIFICATION_ENABLE: The system or controller must support the following notifications within SET_NOTIFICATION_ENABLE:
  • Supported Provider Capabilities Change
  • Negotiated Power Level Change
• GET_CONNECTOR_STATUS: The system or controller must support these connector status changes within GET_CONNECTOR_STATUS:
  • Supported Provider Capabilities Change
  • Negotiated Power Level Change

For information about the tasks required to implement UCSI in the BIOS, see Intel BIOS Implementation of UCSI.

Example flow for UCSI

The examples given in this section describe interaction between the USB Type-C hardware/firmware, UCSI driver, and the operating system.

DRP role detection

1. USB Type-C hardware/firmware detects a device-attach event and the Windows 10 system DRP system initially becomes the UFP role.
   1. The firmware sends a notification indicating a change in the connector.
   2. The UCSI driver sends a ​ GET_CONNECTOR_STATUS request.
   3. The firmware responds that its Connect Status = 1​ and Connector Partner Type = DFP. ​
2. The drivers in the USB function stack responds to the enumeration.
3. The USB connector manager class extension recognizes that the USB function stack has loaded and hence the system is in the wrong state. It tells the UCSI driver to send Set USB Operation Role and Set Power Direction Role requests to the firmware.
4. USB Type-C hardware/firmware initiates the role-swap operation with the DFP​.

Detecting a charger mismatch error​ condition

1. USB Type-C hardware/firmware detects that a charger is connected and negotiates a default power contract. It also observes that the charger is not providing sufficient power to the system.

2. USB Type-C hardware/firmware sets the slow charging bit.

   1. The firmware sends a notification indicating a change in the connector.
   2. The UCSI driver sends a ​ GET_CONNECTOR_STATUS request.
   3. The firmware responds with Connect Status = 1​, Connector Partner Type=DFP, and Battery Charging Status = Slow/Trickle.

3. The USB connector manager class extension sends notification to the UI to display the charger mismatch troubleshoot message.

How to test UCSI

There are a number of ways to test your UCSI implementation. To test individual commands in your UCSI BIOS/EC implementation, use UCSIControl.exe, which is provided in the MUTT Software Pack. To test your complete UCSI implementation, use both the UCSI tests that can be found in the Windows Hardware Lab Kit (HLK) and the steps in the Type-C Manual Interop Procedures.

UCSIControl.exe

You can test individual commands in your UCSI BIOS/EC implementation by using UCSIControl.exe. This tool enables you to send UCSI commands to the firmware through the UCSI driver. It requires the driver to be loaded and running, and also have the test interface to the driver enabled. By default, this interface is not enabled so as to prevent it from being accessible to unauthorized users on a retail system.

1. Locate the device node in Device Manager (devmgmt.msc) named UCSI USB Connector Manager. The node is under the Universal Serial Bus controllers category.

2. Right-click on the device, and select Properties and open the Details tab.

3. Select Device Instance Path from the drop-down and note the property value.

4. Open Registry Editor (regedit.exe).

5. Navigate to the device instance path under this key.

   HKEY_LOCAL_MACHINESystemCurrentControlSetEnum<device-instance-path>Device Parameters

6. Create a DWORD value named TestInterfaceEnabled and set the value to 0x1.

7. Restart the device by selecting the Disable option on the device node in Device Manager, and then selecting Enable. Alternatively, you can simply restart the PC.

You can view the help by running UcsiControl.exe /?.

Here are the common commands:

Related topics