You know it by a hundred names. It's that "extra" SE block you are supposed to use before just diving straight down to your design level (maybe across more than one functional analysis layer). Maybe you know it as a logical subsystem or as a conceptual subsystem. It is the bridge (if required, and it typically is) between «blackbox» scenario Activities that serve a UseCase and the rest of your «whitebox» analysis zone down eventually to the actual design and implementation level (the exact meaning of which depends on your domain).
In the Webel recipe for pragmatic SE with SysML, a '$' prefix in a Block name indicates a «logical» system, a «logical» subsystem (aka conceptual subsystem), or a more specific «logical» handler Block. This is in addition to any other applied Webel SE stereotypes, and makes use of logical subsystems clear even when stereotype keywords are not displayed on symbols in diagrams.
A «logical» handler Block refers in the Webel recipe to a specific kind of «logical» subsystem, one that serves to collaboration to serve one «whitebox» Behavior (tracing either directly or indirectly to a scenario Behavior that serves one Use Case):
Terminology: A «logical» subsystem is not a "logical layer"
To avoid confusion, in the Webel terminology, a "slice" through a system from the point of view of say, «electrical» or «mechanical» stakeholders is called a logical layer (and does not represent a specific collaboration to achieve just one Behavior). Stereotypes for logical layers can also be applied to elements from both to the 'problem' and 'solution' zones.
TIP: A view of logical layer for specific stakeholders can be extracted by querying on its custom stereotypes, perhaps across many different element types: