移动应用对法规要求的适配

技术领域

本公开涉及用于确定被配置为表征多个运输模式中的一个或多个运输模式的一个或多个运输参数的系统和方法。特别地，本公开涉及用于确定一个或多个运输参数以便于在动态变化和/或诸如支付要求的可变要求之前使移动应用适配于法规要求的系统和方法。

背景技术

近年来，市区中的移动性在法规要求方面已发生了许多变化。由于与市区中个体运输增长普遍相关联的问题，许多城市已越来越多地采取了措施来规范个别城市的交通，例如通过收取城市通行费或者通过禁止或以其他方式限制特定车辆进入或穿过城市的某些部分。

预计法规要求在未来将变得更为复杂和多样化，当用户在一个城市内、不同城市之间或者不同国家之间旅行时，用户面临的法规和要求可能会非常不同。将预计，除了已知法规之外，需要考虑不断增加的额外的因素，例如车辆造成的局部排放(例如，测量到的局部空气质量或车辆一般满足的排放标准)、影响城市交通的动态效应(例如，高峰期、特定事件、建筑区)以及其他因素。

对于车辆的用户，这种情况使得难以在城市内的任何地方旅行，尤其难以在不同城市之间旅行，这是由于即使单个国家内的每个城市也可能实施不同的法规。进一步，当由于较低的空气质量或事件引起的限制临时实施或者永久实施时，在城市内驾驶、驾驶到城市中和/或穿过城市可能会受到随时间变化的法规的影响。

同样，交通或运输管理局和市政府可能希望实施考虑了某些参数的可变和/或动态的法规，基于这些参数，可以更有效地指导、限制或控制个别城市的交通。例如，根据当前测得的空气质量或其他因素，对个别城市的交通进行限制可能是有益的，以便于改善交通流量和/或以便于改善空气质量。在一些情况下，可能会落实不允许某些车辆(例如，使用内燃机(ICE)的车辆)进入城市中的某些区域的法规。在其他情况下，这类法规可能仅在特定工作日或一天中的特定时间进行实施。

进一步，根据多种因素，对公共运输和/或个体运输的用户提供激励以使用特定运输模式可能是有益的。例如，在一些情况下，可能需要对众多用户提供激励以使用公共运输(例如，在空气质量低或者拥堵严重期间)，而在一些其他情况下，对众多用户提供激励以使用其他运输模式可能是有益的(例如，在公共运输利用达到高峰值时或者当公共运输服务出现问题或延误时)。

因此，需要允许用户确定最佳运输模式的系统和方法，其能够考虑不同的变化和/或可变的法规要求。

进一步，需要允许确定和/或强制实施法规要求以便优化交通、尤其是城市交通的系统和方法。

另外，需要无缝集成到现有系统、例如基于车辆中已知导航系统的那些现有系统和通常在用户智能手机上发现的那些现有系统的系统和方法。

特别地，需要一种后端组件(例如，服务器、服务)，该后端组件能够实施这类系统和方法并为基础实施、网络和/或后端连接用户设备(例如，智能手机、车载信息娱乐系统)设置提供服务的后端组件。

发明内容

上面指出的一个或多个目的基本上通过根据任一所附权利要求所述的用于确定一个或多个运输参数的方法、后端组件、用户设备和系统得以实现，其减轻或消除了一个或多个上述缺点并实现了一个或多个上述优点。

在根据本发明的第一方面中，提供了一种用于确定表示多个运输模式中的一个或多个运输模式的一个或多个运输参数的方法。多个运输模式中的每个运输模式表示运输环境中的一个或多个用户的运输。该方法包括：从用户设备接收运输请求；基于下述确定一个或多个运输参数：运输请求；用于多个运输模式中的每个运输模式的一个或多个运输模式参数，所述一个或多个运输模式参数表示相应的运输模式；以及表示预计要使用一个或多个运输模式的运输环境的一个或多个环境参数；以及将一个或多个运输参数提供至移动设备。

在根据方面1所述的第二方面中，环境参数包括施加在运输环境中的一个或多个用户的运输上的一个或多个限制的法规参数；可选地，法规参数包括下述中的一个或多个:表示与一个或多个运输模式的使用相关联的一个或多个支付的支付参数；以及表示一个或多个运输模式的适用性的限制参数。

在根据方面1或2任一项所述的第三方面中，一个或多个环境参数包括下述中的一个或多个：一个或多个区域，所述一个或多个区域中的每个区域被配置为与一个或多个运输参数相关联；一个或多个时间参数，所述一个或多个时间参数中的每个时间参数表示时间点、时间段、日期、一天中的时间、工作日、周末和/或假期；一个或多个天气参数，所述一个或多个天气参数中的每个天气参数表示天气条件；可选地，天气条件包括降水、温度、风向、风速、辐射、风寒和/或能见度；以及一个或多个事件参数，所述一个或多个事件参数中的每个事件参数表示事件类型、事件发生和事件周期。

在根据方面1至3任一项所述的第四方面中，一个或多个运输参数表示多个运输模式中的至少两个运输模式，从而基于所述至少两个运输模式能够实现运输环境中的一个或多个用户的运输。

在根据方面1至4任一项所述的第五方面中，该方法进一步包括：从与一个或多个后端组件进行数据通信的一个或多个数据库接收一个或多个环境参数。

在根据本发明的第六方面中，提供了一种用于确定表示多个运输模式中的一个或多个运输模式的一个或多个运输参数的方法。多个运输模式中的每个运输模式表示运输环境中的一个或多个用户的运输。该方法包括：将运输请求提供至一个或多个后端组件；接收来自一个或多个后端组件的响应；基于响应确定表示一个或多个运输模式的一个或多个运输参数。

在根据方面6所述的第七方面中，运输请求包括表示当前由用户使用的运输模式或表示用户打算与运输请求相关联地使用的运输模式的当前运输参数。

在根据方面6或7任一项所述的第八方面中，该方法进一步包括：基于一个或多个运输参数确定偏爱的运输模式；以及可选地将偏爱的运输模式提供至在用户设备上实施的导航系统；或者将偏爱的运输模式提供至用户。

在根据方面6至8任一项所述的第九方面中，该方法进一步包括：将一个或多个运输参数提供至在用户设备上实施的导航系统；或者将一个或多个运输参数提供至用户。

在根据方面6至9任一项所述的第十方面中，该方法进一步包括：将一个或多个运输参数提供至被配置为基于运输参数确定路线的导航系统；可选地，导航系统在用户设备上实施，优选在车辆的控制单元上和/或在移动设备上实施。

在根据方面6至10任一项所述的第十一方面中，运输请求包括以下中的一个或多个：起始位置；目的地；一条或多条路线，所述一条或多条路线中的每一条路线表示起始位置与目的地之间的运输连接。

在根据方面1至11任一项所述的第十二方面中，运输请求包括表示多个运输模式中的一个或多个运输模式的一个或多个第二运输参数；可选地，一个或多个第二运输参数表示有关车辆和/或用户的参数。

在根据本发明的第十三方面中，提供了一种用于提供一个或多个运输参数的后端组件，该后端组件被配置为执行根据本发明的方法，特别是根据前述方面1至5以及11至12任一项所述的方法。可选地，后端组件包括一个或多个服务器和/或一个或多个服务。

根据本发明的第十四方面中，提供了一种用于确定一个或多个运输参数的用户设备，该用户设备被配置为执行根据本发明的方法，特别是根据前述方面6至12任一项所述的方法。

在根据本发明的第十五方面中，提供了一种包括根据方面13所述的后端组件和根据方面14所述的用户设备的系统。

附图说明

附图公开了根据本发明实施例的示例性和非限制性的各方面。在附图中，相同的附图标记指代相同、相似或等同的部件。

图1显示了根据本公开实施例的用于确定一个或多个运输参数的系统的示意图；

图2显示了根据本公开实施例的用于使用系统的示例场景；

图3显示了根据本发明实施例的用于确定一个或多个运输参数的方法的流程图；并且

图4显示了根据本发明实施例的用于确定一个或多个运输参数的方法的流程图。

具体实施方式

在以下详细描述中，除非另有明确说明，否则，利用等同的附图标记指代等同、相同或类似功能的元件。

图1显示了根据本公开实施例的用于确定一个或多个运输参数的系统100的示意图。系统100可至少部分地在车辆80的控制单元120上和/或在移动设备125上实施。系统100可进一步至少部分地在后端组件150(例如，服务器、诸如数据库的服务)上实施。在图1所示的实施例中，系统100包括控制单元120和移动设备125至少之一并在控制单元120和移动设备125至少之一上以及在后端组件150上实施。

车辆80可包括具有内燃发动机(ICE)的车辆、混合动力电动车(HEV)、插电式混合电动车(PHEV)、纯电动车(BEV)、燃料电池电动车(FCEV)或其衍生物或变型。

除了控制单元120之外，车辆80包括被配置为对控制单元120提供数据通信140能力的通信单元130。以此方式，控制单元120以及可操作地联接至控制单元120的其他组件可与其他组件和/或设备、例如后端组件150(例如，服务器、诸如数据库的服务)或用户(未示出)的移动设备125(例如，智能手机、平板电脑)进行数据通信140。通常，通信单元130可利用数据通信140将控制单元120和/或移动设备125提供至通过网络(例如，互联网)可访问的任何(云)服务160。数据通信可基于任何已知的通信标准，例如GSM、EDGE、HSUPA、LTE、5G或其他。进一步，移动设备125可使用相应的数据通信标准(例如，蓝牙、Wifi)可操作地联接至控制单元120。以此方式，控制单元120可经由移动设备125进入数据通信140和/或移动设备125可经由控制单元120进入数据通信140。进一步，表征车辆80和/或车辆80的操作状态的车辆数据可发送至移动设备125和/或经由数据通信140。

在本公开的范围内，控制单元120和移动设备125二者均可称为“用户设备”，由此表明，除非另有说明，使用相应的设备和/或数据通信140与后端组件150对于用户是透明的，并且用户与任何相应设备120、125的交互基本上是相同的。

车辆80可进一步包括被配置为允许车辆80的用户与系统100进行交互的用户接口110。另外或者可替代地，移动设备125可进一步包括被配置为允许移动设备125的用户与系统100进行交互的用户接口110’。在优选实施例中，用户可以利用两个用户接口110和110’无缝地使用系统100，选择从一个接口改变至另一个接口和/或在两个接口110和110’之间交替。用户接口110和/或110’可包括例如触摸屏的输入/输出组件。系统100可提供有另外的用户接口(未示出)，该另外的用户接口允许用户例如通过使用网络浏览器、语音识别、手势控制或其他输入/输出模式与系统100进行交互。

在第一优选实施例中，系统100至少部分地在车辆80的控制单元120上实施，在此情况下，车辆80的控制单元120可以与后端组件150直接(例如使用通信单元130)或间接(例如使用移动设备125)进行数据通信140。用户可使用用户接口110和110’中的一个或者两个与系统100进行交互，而在该第一优选实施例中，可主要使用车辆80的用户接口110执行用户交互。

在第二优选实施例中，系统100至少部分地在用户的移动设备125上实施，在此情况下，移动设备125可以与后端组件150直接(例如使用数据通信标准)或间接(例如使用车辆80的控制单元120和通信单元130)进行数据通信140。用户可使用用户接口110和110’中的一个或者两个与系统100进行交互，而在该第二优选实施例中，可主要使用移动设备125的用户接口110’执行用户交互。

在第三优选实施例中，系统100至少部分地在用户的移动设备125上实施。进一步，移动设备125与后端组件150仅仅直接(例如不使用车辆80的控制单元120和/或通信单元130)进行数据通信140。该第三优选实施例适用于用户不使用车辆80和/或用户使用不需要使用车辆80(例如，当从车辆80变化至公共运输时)的运输模式的情况。用户于是可使用移动设备125的用户接口110’与系统100进行交互。

后端组件150可包括例如服务器和/或服务的一个或多个资源，并且可被配置为向此类服务器和服务提供(另外的)数据通信。服务器和/或服务可以直接连接至后端组件150或集成到后端组件中(例如，参见数据库156)，或者经由网络连接(例如，参见云服务160)间接连接。后端组件150可与控制单元120和/或移动设备125进行永久数据通信140，或者数据通信140可在需要时被激活。

后端组件150访问被配置为表征其中预计要使用一个或多个运输模式的运输环境的环境参数。运输模式可指一个或多个路网(例如，使用私人拥有或操作的车辆、或临时租用的车辆或共享汽车车辆的个体交通)、一个或多个公共运输网(例如，公共汽车、电车、地铁、火车)、一个或多个运输服务提供商(例如，拼车、出租车服务、Uber、Lyft)、一个或多个道路和人行道网络(例如，用于行人交通、自行车交通、包括自行车租赁/共享)以及其他模式。在城市环境中，环境参数特别地可包括被配置为表征用于使用一个或多个运输模式的条件(例如，管制、豁免、限制)以及分区信息(即适用一个或多个法规参数的特定分区或区域的限定)的法规参数。环境参数可进一步包括其他条件(例如非法规)，例如天气信息(例如，降水、温度、风向或风速、诸如UV指数的辐射、风寒、能见度)，包括空气质量和/或颗粒排放物(例如，包括空气中包含的NO

后端组件可包括一个或多个服务器和/或一个或多个服务，其又能访问其他组件，例如经由例如云160中的网络连接能访问的一个或多个数据库156和/或多个服务器和/或服务。注意到，一个或多个服务器和/或一个或多个服务中的每一个可由不同实体操作，从而用户可透明地访问系统100，而无需知道访问哪个个体服务器/服务150和/或任何此类服务器或服务的提供商是谁。

例如，环境参数可由若干不同实体提供。例如公共运输提供商的第一实体可提供公共汽车、电车和地铁的调度时间、以及有关票价、服务中断(例如，当服务受到特殊事件或故障影响时)的相关联的数据、以及其他相关信息。另一公共运输提供商可提供有关城市和/或区域火车网络的相同或相似信息。又一实体(拼车服务的提供商)可提供有关可用乘车、定价方案、特价等的信息。再一实体(例如市运输局)可提供与城市和/或区域路网有关的信息，例如与当前和/或预期/预测拥堵、建筑工地、通行费、停车费和/或管制有关的信息。有关停车位置的信息以及任何相关联的信息(例如，停车费、特价)也可由私营企业提供。

在优选实施例中，根据处理要求和环境，可以由控制单元120、移动设备125和/或后端组件150中的任一个或者由经由后端组件150可访问的组件执行处理步骤。在优选实施例中，由后端组件150或由经由后端组件150可访问的组件执行资源密集型处理，从而控制单元120和/或移动设备125仍然可用于其他任务，特别是那些需要本地执行的任务。资源密集型处理可包括由于例如处理能力、可用存储器资源和/或数据可用性和/或带宽考虑方面的有限资源而不能在控制单元120和/或移动设备125上有效(或者根本不能)执行的处理。

特别地，环境参数可包括表示在运输环境中施加在用户运输上的一个或多个条件(例如，管制、豁免、限制)的法规参数。

在一个示例中，环境参数和/或法规参数可包括例如城市收费系统的表现形式，基于城市收费系统，对用户强加使用某些运输模式的通行费。法规参数可限定，在城市的特定分区(例如市中心)内使用车辆80会受到城市通行费的影响，该城市通行费可被限定为每公里或每分钟的费用。城市通行费可进一步基于车辆80(例如，电动、ICE)的驱动模式、基于一天中的时间和/或星期几和/或其他因素。以此方式，交通或运输管理局可基于上述因素提供分区信息，在该分区信息中每个分区可与特定的城市通行费相关联。

例如表示内部市中心的第一分区可与只有电动车(或电动模式的混合动力车)可进入第一分区的条件、即管制相关联。第一分区可要求始终向电动车收取0.04欧元/分钟的城市通行费。

表示市中心相邻部分的第二分区例如可以不对非电动车辆强加管制(例如，可以使用非电动车辆)。第二分区可要求基于驱动模式向所有车辆收取城市通行费：ICE车辆为0.06欧元/公里，电动车以及以电动模式操作的混合动力车为0.02欧元/公里。

表示城市另一部分的第三分区可与基于时间和基于驱动模式的城市通行费相关联。在工作日高峰期(例如拥挤时段)、从工作日的上午7点至上午9点以及从下午4点至下午6点期间，第三分区可要求向所有车辆收取0.05欧元/公里的城市通行费。在其他所有时段，向所有ICE车辆收取0.02欧元/公里的城市通行费，不向电动车收取城市通行费。

表示足球场周围区域的第四临时分区可与特定停车费和城市通行费相关联，但是仅在体育馆内举办活动期间。在此期间，可向第四分区中载有包括驾驶员在内三个以上乘客的所有车辆收取5欧元/小时的停车费，而可向载有三个或更少乘客的所有其他车辆收取8欧元/小时的停车费，额外收取驾驶的0.06欧元/分钟的城市通行费。

通常存在多个环境参数，基于环境参数可限定下述规则：

·位置；例如，基于坐标、地块、路段、路网元素限定的分区

·一天中的时间；例如，高峰期、拥挤时段

·星期几；特别是工作日、周末、节假日

·天气条件；例如，降水、温度、风向或风速、辐射(例如UV指数)、风寒、能见度

·事件信息；例如，一次性事件、定期发生的事件

·空气质量和/或颗粒排放物(例如，包括空气中包含的NO

·交通密度

进一步，存在多个运输参数，基于运输参数可限定下述规则。运输参数特别地可包括表示正在使用的运输模式(例如正在操作的车辆80)的参数：

·运输模式；例如，车辆、公共运输、公共汽车、电车、火车、地铁

·操作模式；例如，使用ICE的车辆、使用电驱动的混合动力或电动车辆

·统计使用信息(例如，过去30天在预定市区中例如PHEV的车辆进行电驱动公里所占的份额)

·车辆类型；例如，ICE、柴油、汽油、HEV、PHEV、BEV

·规格和/或性能；例如，排放标准(例如，EU4、EU5、EU6)、排放特性(例如CO

·车辆的车辆识别码(VIN)

·定位信息(例如，GPS)

·里程信息(例如，公里、英里)

·操作时间；例如，计划的旅行时间、不同位置和/或某些区(例如区域)内花费的时间

·路线信息；例如，预定路线、停留处

·车辆的登记国家

·私人或企业用途的车辆

·车辆重量

·车辆轴数

·车辆的额定功率/输出

·特定的用户信息，例如收入水平

以上示例可以任何所需方式进行组合，从而环境、法规和/或运输参数的任意组合基本上可用于指导、调节和/或控制运输。

注意到，运输请求可包括上述运输参数中的一个或多个。这意味着，用户设备可被配置为将运输请求形式的上述运输参数中的一个或多个通信至一个或多个后端组件150，从而一个或多个后端组件可考虑这种运输参数。特别地，用户设备120、125可因此能够提供车辆80的特定参数(例如，操作模式、统计使用信息、车辆类型、规格和/或特性、VIN、定位信息、里程信息、操作时间、路线信息、注册信息、车辆使用指示、重量、轴数、车辆的额定功率/输出等)。进一步，用户信息可包括在运输请求中，用户信息表示用户(例如，性别、年龄、收入水平、当前状态/状况)。用户设备120、125可因此能够提供有关用户的特定细节。这种用户相关的参数可基于隐私问题和/或法规严格实行，并且可以用户确认他们愿意与后端组件150共享这种信息为条件。图2显示了根据本公开实施例的用于使用系统100的示例场景。图2示例性地例示了市区200，该市区为用户提供一个或多个运输模式，例如与车辆80一起使用的路网、公共运输(例如，公共汽车、电车、地铁、火车)以及用于步行和/或自行车的道路和人行道网络。为了简单起见，图2关注于用户正在路线86(见图2的点划线)上在车辆80(未按比例)中对市区200进行导航的场景。其他运输模式在不背离本公开的关键概念的情况下同样适用。

市区200被显示为划分成由相应的边界212、222和232限定的若干区域210、220和230。图2中所示的划分包括多边形区域(或边界212、222和232)，其可基于例如坐标(例如GPS坐标)自由限定，而一系列坐标被配置为限定相应的区域(例如，闭合多边形的形式)。例如，市区200中所示的城市中心由区域230表示，该区域被显示为大致位于市区200的中心并由边界232界定。紧邻市中心的区域、即因此区域230由区域220表示，该区域由边界222界定。如所示，区域220包括市区200的较大部分(即，远大于区域230覆盖的部分)。然而，通常，图2中所示的划分仅为示例，本公开的概念通常允许任意多边形(或者其他)划分，因此允许任意大小和/或覆盖范围的区域。图2进一步显示了区域210，该区域由边界212界定并与区域220相邻并大致在区域220北部(方向“北部”可被限定为面朝图2的顶部)。区域210和220共享其各自边界212和222的一部分。区域230完全位于区域220内，而没有公共边界。

通常，可以实施划分市区200的许多其他方法。例如，可应用基于矩形或方形地块的规则划分，从而市区200被分成多个地块(例如，类似于棋盘)。因此，可根据一个或多个地块限定任意区域。这可以在空间处理(例如，确定地理位置是否位于特定区域内)中带来优势。进一步，地块和/或划分可能取决于一个或多个参数，例如，人口统计参数(例如，分区信息、人口密度)、结构参数(例如，街道或路网、广场或地标)或者允许地块和/或划分的其他参数。以此方式，可限定与特定分区有关或者覆盖预定部分的人口的地块。

划分市区200的其他方法可包括基于诸如路网、公共运输网络或虚拟网络(例如，在市区200中运行的多个公交线路)的结构特征的划分。根据所使用的运输模式和/或个体应用，不同类型的划分可能是有益的和/或提供某些优势。

不同区域、例如区域210、220和230对于不同的运输模式可提供有特定的环境和/或运输参数。环境和/或运输参数可包括多个不同参数，例如关于支付(例如，城市通行费、拥堵费、停车费、公共运输费用)、关于一般用途(例如，用于某些类型车辆的条件或管制)、临时参数(例如，高峰时段的附加费、一天中某一时段或一周中某些天的管制)、激励(例如，高峰时段的动态定价、特殊事件、游戏化、社交评分)和其他类别。系统100被配置为集成如上所述的若干不同运输参数。

例如，城市通行费通常可以是固定的，但定价方案对于每个区域210、220和230可能不同。例如，在区域220和230中利用车辆80行驶可能被收取城市通行费，区域230的通行费高于区域220的通行费。进一步，区域210也可收取通行费，该通行费低于区域220中的通行费。系统100可被配置为根据请求基于一个或多个地点和/或基于通过市区200的路线提供通行费信息。

进一步，可以基于日期和/或时间动态地调整城市通行费。以此方式，可以在交通通常比非高峰时段严重得多的高峰时段期间调整定价方案。因此，可包括在高峰时段期间频繁使用的一个或多个路线的区域210的城市通行费在高峰时段(例如，工作日上午7点至上午9点以及下午3点至下午6点之间)期间可能增加。区域220、230的定价方案也可调整。例如，在节假日或周末期间，可降低对一个或多个区域的城市通行费。

而且，可以基于针对一个或多个区域确定的污染水平动态地调整城市通行费。以此方式，在检测到污染水平增大的时段期间或者在预测到这种污染水平增大的时段期间可以限制车辆交通。另外或可替代地，可基于污染(例如增大)来调整城市通行费，由此使得在污染增大时段期间使用车辆更为昂贵。以类似的方式，另外或可替代地，在污染增大的时段期间停车费也可增加，从而使得在此期间使用车辆更为昂贵。可动态地调整所有这些措施，从而，一旦污染恢复至可接受水平，则可调整条件、管制、定价方案和/或激励。

关于其他运输模式，这也可会产生影响。例如，可调整(例如降低)公共运输的定价，从而激励旅客在污染增大时段期间使用公共运输而非个体车辆。

在基于市区200和图2所示划分的第一示例中，用户往往沿着路线86穿过区域210和220，起始位置位于市区200外，目的地位于区域230中。车辆80是PHEV类型，这有助于使用ICE、电驱动或其组合的操作。在该第一示例中，关于城市通行费的下述规定是固定的：

·区域210：

ο城市通行费-EV：0.02欧元/公里(工作日周一至周五)

ο城市通行费-PHEV：0.02欧元/公里(工作日周一至周五)

ο城市通行费-ICE：0.03欧元/公里(工作日周一至周五)

ο周末没有城市通行费(所有车辆)

·区域220：

ο城市通行费-EV：免费

ο城市通行费-PHEV：如果以电驱动模式操作(例如，特定市区内>80％行程为电驱动)则免费，否则按照ICE收费

ο城市通行费-ICE：0.04欧元/公里

·区域230：

ο城市通行费-EV：0.01欧元/公里(+10％附加费上午8点至上午10点，下午4点至下午6点)

ο城市通行费-PHEV：0.03欧元/公里(+10％附加费上午8点至上午10点，下午4点至下午6点)

ο城市通行费-ICE：0.04欧元/公里(+10％附加费上午8点至上午10点，下午4点至下午6点)

为了准备开车进入城市，用户可通过向在车辆80的控制单元120上实施的导航系统提供目的地来指定路线86。导航系统可基于已知准则(例如，最短行程时间或最短距离)生成推荐路线。在第一示例中，导航系统已提供了如图2所示的路线86。

然后，路线86可被发送至后端组件150，从而请求有关路线86的运输参数和预计行程时间(例如，立即启动)。例如可利用如上所述的数据通信140联系后端组件150。后端组件150访问有关市区200的运输参数和环境参数，例如表示区域210、220、230的参数、表示城市通行费和管制的参数等。参数可存储在数据库156上，或者可由后端组件150以其他方式(例如，通过云服务160)访问。后端组件150可确定路线86通过的任何区域，在此第一示例中为区域210、220、230，并基于预计行程时间确定城市通行费信息。因此，后端组件150可以提供表示用户打算穿行的区域的固定城市通行费的运输参数。

在第一示例中，后端组件150仅仅提供所有相关的运输参数，而与车辆80的类型无关。用户可利用车中的控制单元120(例如，经由导航系统直接地)接收运输参数，因此用户不仅被提供有路线和估计的到达时间，而且还提供有预计的出行费用。出行费用因此可取决于车辆80的操作模式。如果车辆80在整个出行中以ICE模式操作，则与车辆80以电驱动操作相比，预计费用更高。用户可基于后端组件150提供的运输参数进一步选择车辆80的对应操作模式。或者，导航系统提出替代运输模式或者运输模式的组合，例如将私家ICE车辆停放在停车转乘设施并转换至BEV共享车辆，或者甚至转换成公共运输。

在优选实施例中，导航系统可至少部分地基于运输参数在费用方面进一步优化路线。这可包括：在与路线相关联的费用方面(例如费用最低)找到满足特定需求的路线和/或对现有路线找到运输模式和/或操作模式(例如，对于车辆；电动或ICE)以便优化费用。

在优选实施例中，用户设备120、125可被配置为提供优化(例如，费用优化)的驱动模式推荐，其中车辆80的控制单元120被配置为提供用于车辆80沿着路线86所穿过的每个区域210、220和230的优化驱动模式的推荐。因此，车辆80的用户可根据所提出的推荐进行改变以切换车辆80的操作模式，因此优化所进行的出行(例如，在费用方面，即城市通行费)。

在其他优选实施例中，控制单元120可被配置为提供优化(例如，费用优化)的驱动模式推荐，其中车辆80的控制单元120被配置为对于车辆80沿着路线86所穿过的每个区域210、220和230自动选择费用优化的驱动模式，而无需用户进行交互。以此方式，控制单元120可针对每个出行区域选择优化的驱动模式，由此在用于城市通行费的费用方面对出行进行优化。

用户的移动设备125也可便于以上情况，如果利用移动设备125与后端组件150进行数据通信，则移动设备可对车辆80的控制单元120提供运输参数。

其中系统100可优选在用户设备(例如移动设备125)上实施的一个示例性示例是汽车共享领域。当使用汽车共享服务时，用户行驶所用的车辆通常会频繁改变，从而通常使用不同的车辆完成每一出行。在这类情况下，用户可对移动设备125上的对应应用程序(例如，App)提供所有必需信息(例如，包括姓名、地址、驾驶证、支付选项等的配置文件信息)，以便能够使用系统100。移动设备125可直接与后端组件150通信，以便为后端组件提供路径信息和/或运输请求等，并且以便从后端组件150接收运输参数。在优选实施例中，移动设备125与当前使用的相应车辆进行数据通信，并且可以例如根据请求从车辆接收运输参数(例如，VIN号、车辆类型、当前操作模式、位置；见上文)。在这类情况下，可通过移动设备125的用户接口110’进行用户与系统100的全部或至少部分交互。发送运输请求(例如，包括路线信息、运输参数)的一般过程可以与如上所述的第一示例基本相同，除了用户与移动设备125的用户接口110’的交互更多或者更专用。在这类情况下，可如上所述那样使用车辆的导航系统，尽管也可使用在移动设备125上运行的对应的应用程序(例如，导航App)。

在基于第一示例的第二示例中，管理市区200的交通局检测到例如由于特定的天气条件导致的污染水平增大。响应于此，系统100可提供若干措施来引导、调节或控制交通。首先，可调整公共运输定价(例如，可降低票价)，以便于为用户提供额外或增大的激励来使用公共运输。其次，对于以ICE模式操作的车辆以及对于ICE车辆和/或对于受污染水平增大影响的区域，可临时增加城市通行费(例如，增加50％)。第三，零排放车辆(例如，BEV、HEV、PHEV)可临时免除所有的城市通行费，或者可提供降低(例如，-50％)。第四，受污染水平增大影响的区域可受到管制，从而以ICE模式操作的车辆或者对于ICE车辆可临时禁止进入这些区域。这类管制还可基于特定的管制规则，例如，只有一部分注册车辆可以基于该特定的管制规则进入这些区域。示例性的管制规则可包括基于车牌或VIN号码选择车辆，从而在某一天只有具有偶数的车辆可操作，而在其他天仅具有奇数的车辆可在这些区域内操作。

通常，关于第一示例和第二示例，系统100可被配置为提供有关多个运输模式的运输参数，从而对用户提供有关运输请求的替代选项。例如，系统100可被配置为向用户提供替代路线，该替代路线与用户提供的路线86具有相同的目的地。此类替代路线可与路线86一样被限制于相同的运输模式，但对用户提供一些优势或优化(例如，路线更短、路线更快、路线更便宜)。此类替代路线可替代地可包括一个或多个替代运输模式，特别是多个运输模式的组合。在如上所述的第一示例和第二示例中，可对用户提供包括使用公共运输的一个或多个替代路线。在这种替代路线中，可向用户提供将其车辆80留在停车转乘地点的选项，用户在停车转乘地点可变换至另一运输模式，例如公共运输。系统100可被配置为向用户提供个性化的路线信息(例如，有关费用、行程时间、距离)，从而用户可确定偏爱的一个或多个运输模式来使用。

一些实施例可包括社交评分系统，其被配置为跟踪用户的运输行为并对所涉及的用户的个体运输进行奖励积分或进行处罚。例如，对于使用环境友好的运输模式，可对用户奖励积分，而对于使用其他运输模式，同一用户可接受处罚。进一步，对于避免公共运输的高峰时段和/或避免高峰期使用车辆出行，可对用户奖励积分，而未能避免则可进行处罚。系统100可被配置为至少部分地基于与用户相关联的社交评分来提供运输参数。

图3显示了根据本发明实施例的用于确定一个或多个运输参数的方法300的流程图。一个或多个运输参数表示多个运输模式中的一个或多个运输模式，多个运输模式中的每个运输模式表示运输环境中的一个或多个用户的运输。方法300在步骤301开始。

在步骤302，从用户设备120、125接收运输请求。用户设备可包括车辆80的控制单元120和/或用户的移动设备125。在优选实施例中，用户设备可包括控制单元120或者移动设备125或二者的组合，并且系统100可被配置为便于无缝集成和/或从一个到另一个的切换。这意味着用户可利用移动设备125发起请求，例如在去往车辆80的路途上，在请求正被处理的同时，用户可进入车辆80并且移动设备125可连接至车辆80的控制单元120。随后，用户请求的运输参数不仅可在移动设备125处接收或者经由该移动设备接收，而且直接在控制单元120处接收或者经由该控制单元接收。反过来也可以实现相同情况，例如，当用户已在车辆80中开始出行时并沿途某一时刻利用不同的运输方式(例如，公共运输、共享汽车；参见上文)继续出行时，在此情况下，从车辆80(其可停在停车转乘设施处)的控制单元120透明切换至用户在剩余出行所携带的移动设备125(例如，用户的智能手机)。

在步骤304，可选地，从与一个或多个后端组件150进行数据通信的一个或多个数据库156接收一个或多个环境参数。如上所述，可被配置为执行方法300的步骤的一个或多个后端组件可包括一个或多个服务器和/或一个或多个服务，并且可由一个或多个(不同的)实体操作。优选地，通常可从不同的数据库156和/或不同的数据源(例如，从数据库156和/或从云服务器和/或服务和/或其他源)获得环境参数。在优选实施例中，用户设备120、125可与单个服务器和/或服务进行数据通信140，其又向用户设备120、125提供将用户设备120、125连接至多个另外的服务器和/或服务的单个接口(例如，应用程序接口、API)。

在步骤306，基于运输请求、一个或多个运输模式参数以及一个或多个环境参数确定一个或多个运输参数。对于多个运输模式中的每个运输模式，一个或多个运输参数表示相应的运输模式。这意味着，对于每个运输模式，运输模式参数在使用运输模式所需的信息方面和/或在将运输模式集成到出行中所需的信息方面表示(例如，限定)运输模式。一个或多个环境参数(参见上文)表示其中预定要使用一个或多个运输模式的运输环境。如上所述，确定一个或多个运输参数考虑了上述参数，以便提供允许对运输请求限定的出行进行优化的运输参数。换言之，用户或用户设备可在提供目的地时生成请求，并启动方法300，以便确定允许实现出行的对应的运输参数。

在步骤308，将一个或多个运输参数提供至移动设备120、125。如上所述，可将一个或多个运输参数提供至车辆的控制单元120和/或提供至移动设备125。

在步骤310，可选地，确定是否需要处理另外的请求。如果是，则从步骤302重复方法。在优选实施例中，方法300由一个或多个后端组件150执行，其中一个或多个后端组件150被配置为连续地等待从一个或多个用户设备120、125接收到的运输请求。根据每个运输请求，然后由一个或多个后端组件150执行上述步骤302至308。

方法300在步骤312结束。

图4显示了根据本发明实施例的用于确定一个或多个运输参数的方法400的流程图。一个或多个运输参数表示多个运输模式中的一个或多个运输模式。多个运输模式中的每个运输模式表示运输环境中的一个或多个用户的运输。方法400在步骤401开始。

在步骤402，将运输请求提供至一个或多个后端组件150。运输请求可包括起始位置、目的地和一条或多条路线中的一个或多个。一条或多条路线中的每一条路线表示起始位置与目的地之间的运输连接。进一步，运输请求可包括表示当前由用户使用的运输模式或表示用户打算与运输请求相关联地使用的运输模式的当前运输参数。换言之，当用户设备向一个或多个后端组件150提供运输请求时，该请求可包括预期目的地(例如，由用户输入限定)、起始位置(例如，由用户设备提供，例如由GPS提供)和/或预期路线(例如，导航系统提供的一条路线)。运输请求可进一步包括有关运输模式的信息，例如包括当前的车辆参数(例如，当前占用哪种操作模式)和固定的车辆参数(例如，车辆类型、规格、排放等级)。用户在运输请求中可进一步包括用户倾向使用的一个或多个希望的运输模式和/或用户倾向不使用的一个或多个不希望的运输模式。

在步骤404，接收来自一个或多个后端组件150的响应。并且，在步骤406，基于该响应确定表示一个或多个运输模式的一个或多个运输参数。然后可由用户设备120、125以若干方式使用一个或多个运输参数。例如，可以对用户提供计划出行的费用估计和/或同一出行(例如，相同目的地)的若干替代路线的选择以及相关联的费用。在自动驾驶车辆的情况下，车辆可被配置为基于运输参数确定用于预设出行的最佳路线。

在步骤410，可选地，确定是否由一个或多个后端组件150处理另外的请求。如果是，则从步骤402重复方法。在优选实施例中，方法400由用户设备120、125执行，其中用户设备120、125被配置为向一个或多个后端组件连续地提供运输请求，只要一个或多个请求待定和/或等待响应。根据每个运输请求，由用户设备120、125执行上述步骤402至408。

方法400在步骤412结束。